Secure Web Application Checklist for UAE Businesses

A web application is often where a business keeps its most valuable data: customer details, prices, invoices, contracts. When it is breached or goes down, the consequences are business consequences: customer data exposed, operations stopped, contracts put at risk, and trust that takes years to rebuild. Under the UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021), holding personal data also comes with an obligation to protect it.

This checklist is for owners and IT leads who want to check their own system, or their vendor, against sensible practice without being security specialists. It explains the OWASP Top 10 in plain language, gives a practical checklist grouped by area, suggests how often to test, and lists the questions to put to your developer.

Why web app security is a business risk, not just an IT one

Security failures are rarely exotic. Most come from ordinary gaps: an admin account without multi-factor authentication, a library left unpatched for a year, a page that shows one customer's data to another, a backup that was never tested. These are management issues as much as technical ones, which is why an owner or IT lead should be able to ask the right questions. The legal side of personal data is covered in our article on PDPL obligations for web apps; this page covers the technical controls.

The OWASP Top 10 in plain language

The OWASP Top 10 is a widely used list of the most critical security risks to web applications, published and periodically updated by the OWASP Foundation. Category names and order shift between editions, so check owasp.org for the current list. The risks it covers, in plain terms and with typical UAE business examples:

• Broken access control: users can see or do things they should not. Example: a customer portal user changes a number in the address bar and sees another company's invoices.
• Cryptographic failures: sensitive data is not properly protected. Example: passwords stored in a reversible form, or data sent without HTTPS.
• Injection: user input is treated as code. Example: a search box that lets an attacker run commands against the database.
• Insecure design: the flaw is in how a feature was designed, not how it was coded. Example: a password reset that can be completed with information anyone could find.
• Security misconfiguration: unsafe settings. Example: a test admin panel left reachable from the internet, or error pages that reveal internal details.
• Vulnerable and outdated components: libraries, frameworks or plugins with known flaws. Example: an old plugin with a published exploit that nobody updated.
• Authentication failures: weak login handling. Example: unlimited login attempts and no MFA for administrators.
• Software and data integrity failures: trusting updates, packages or data without checking them. Example: a deployment process that pulls unverified packages.
• Logging and monitoring failures: attacks go unnoticed. Example: nobody would know if an admin account logged in from abroad at 3am.
• Server-side request forgery: the server can be tricked into making requests it should not. Example: an "import from URL" feature used to reach internal systems.

The checklist

Each item is a yes or no question. A "no" is not necessarily a crisis, but it should be a known, accepted decision rather than an oversight.

Access and authentication

• Is multi-factor authentication required for all admin and staff accounts? Admin accounts are the most valuable target.
• Does every person have their own login, with no shared accounts? Shared accounts make actions untraceable.
• Are roles and permissions defined, and is access reviewed at least quarterly? People change roles and leave.
• Are leavers' accounts disabled on their last day?
• Does the server check, on every request, whether this user may access this record? Hiding a button is not access control.
• Are login attempts rate-limited, and are passwords stored with a modern hashing algorithm?

Data protection and encryption

• Is HTTPS used everywhere, including admin pages and APIs?
• Is sensitive data encrypted at rest, in the database and in backups?
• Do you collect only the personal data you actually need? Less data means less to lose.
• Do you know where personal data is stored and who can access it?
• Are card payments handled by a gateway's hosted page or fields, so card numbers never touch your servers?

Input handling and injection

• Does all database access use parameterised queries or a safe data-access layer?
• Is user input validated on the server, not only in the browser?
• Is output encoded to prevent cross-site scripting?
• Are file uploads restricted by type and size, checked, and stored where they cannot be executed?

Dependencies, updates and configuration

• Is there an up-to-date list of the libraries and frameworks the application uses?
• Are dependencies checked automatically for known vulnerabilities?
• Are security updates applied on a schedule, with urgent ones applied quickly?
• Are secrets such as API keys and passwords kept out of source code?
• Are debug modes, test accounts and default credentials removed from production?
• Are security headers, such as a content security policy, set?

Logging, monitoring and incident response

• Are logins, permission changes and sensitive actions logged where they cannot easily be altered?
• Does a named person receive alerts on suspicious activity and errors?
• Is there a written plan for a suspected breach: who decides, who is told, how the system is contained?
• Do you know your obligations if personal data is breached? Take legal advice on notification.

Hosting, backups and data residency

• Are hosting and domain accounts in your company's name, protected with MFA?
• Are backups automated, stored separately from the main system, and test-restored regularly?
• Do you know, and have you documented, which region your data is hosted in? See data residency in the UAE.
• Are servers and databases unreachable from the internet except where they need to be?
• Is there protection against basic denial-of-service and bot traffic?

How often to test: code review, scanning, penetration testing

These cadences reflect common good practice, not a regulatory rule. Adjust them to the sensitivity of your data and how often the application changes.

• Automated dependency scanning: catches known vulnerabilities in libraries. On every build, and at least weekly.
• Code review: catches logic and access-control mistakes before they ship. On every change.
• Automated vulnerability scanning: catches common misconfigurations and known issues in the running application. At least quarterly, and after significant releases.
• Penetration testing: a skilled tester actively tries to break in, finding business-logic and access-control flaws that scanners miss. At least annually, and after major changes.
• Access review: quarterly.
• Backup restore test: at least twice a year, and after any change to the backup setup.

A scan and a penetration test are not the same thing. A scan is automated and looks for known patterns; a penetration test is a person thinking like an attacker. You need both.

Questions to ask your developer or agency

1. Who has access to production systems and data, and how is that reviewed?
2. Is MFA enforced on our hosting, code repository and admin accounts?
3. How are dependencies monitored and patched, and how quickly are critical patches applied?
4. Where are secrets stored?
5. Is every change code-reviewed before release?
6. When was the last penetration test, and can we see the summary and what was fixed?
7. Where is our data hosted, and where are the backups?
8. When was a backup last restored successfully?
9. What is logged, and who would notice an attack?
10. What would you do in the first hour after a suspected breach?

Securing an existing application: where to start

If the checklist turned up more "no" answers than you would like, do not try to fix everything at once. A sensible first 30 days:

1. Inventory: list the applications, hosting accounts, domains, admin users and third-party services.
2. Access review: remove leavers and unused accounts, enforce MFA and end shared logins.
3. Patching: update frameworks, libraries and plugins with known vulnerabilities, most severe first.
4. Backups: confirm backups exist, are stored separately and can actually be restored.
5. Testing: run a vulnerability scan, then commission a penetration test once the obvious issues are fixed.

Security is not a one-off project. It needs ongoing patching and monitoring, which is a core part of ongoing patching and support. And if you are commissioning a new system, building security in from the start is far cheaper than retrofitting it; it is part of how we approach secure web application development.