We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Audit and compliance
  3. Website security audit
Website and web application security audit, UAE

Software supply chain failures entered the OWASP Top 10 at number three. Most organisations cannot list what their site depends on.

The OWASP Top 10 2025 is the current edition, and the categories have moved. Broken access control remains first, security misconfiguration second, and software supply chain failures now sit at third. An audit against the current list tells you where your applications actually stand rather than where the 2021 list said they did.

Book a web application auditSee the current Top 10
Website and web application security audit for UAE organisations
  • Top 10 2025The current released edition
  • A01 access controlStill the first category
  • A03 supply chainDependencies, and what they pull in
  • ConfigurationSecond category, and rarely tested
What we test

Six things that decide whether a web audit finds anything real.

The OWASP Top 10 is the reference every serious web application audit works against, and the 2025 edition is the current released version. Testing against a superseded list, or against a scanner default profile, produces findings that are true and no longer the ones that matter most.

Broken access control, still the first category

A01 in the 2025 edition, as it was previously. It is first because it is both the most common and among the most damaging: a user reaching data or functions belonging to another user, or to an administrator. Automated tools find some of it. The rest requires somebody understanding what the application is supposed to allow, which is why access control testing is the least automatable part of a web audit.

Security misconfiguration, at number two

A02 in 2025. Default credentials, verbose errors, unnecessary features enabled, missing hardening on the platform underneath the application, headers absent. It is second because it is everywhere and cheap to exploit. It is also the category most often missed by an audit scoped only to the application code, because the finding lives in the deployment rather than the source.

Software supply chain failures, now at number three

A03 in the 2025 edition. Modern web applications are assembled from dependencies, and each dependency has dependencies. The audit question is not only whether a known vulnerable package is present, but whether anybody can produce the list at all, and whether the build process would notice if something in it changed.

Cryptographic failures and injection

A04 and A05 respectively. Cryptographic failures cover data that should have been protected in transit or at rest and was not, or was protected badly. Injection remains present in the current list, which after two decades of attention says something about how applications continue to be built under time pressure.

Design, authentication and integrity

A06 insecure design, A07 authentication failures and A08 software or data integrity failures. The first of those is the category a scanner cannot reach at all, because it concerns decisions made before any code was written. Finding it requires reading how the application is supposed to work rather than probing how it responds.

Logging, alerting and exceptional conditions

A09 security logging and alerting failures, and A10 mishandling of exceptional conditions. Both are about what the application does when something goes wrong: whether anybody would know, and whether the failure itself creates an opening. They sit at the bottom of the list and they are consistently the two nobody has looked at.

What changed, and why it matters

The list moved. An audit written against the 2021 categories is measuring the previous decade.

OWASP publishes the current edition and keeps the older ones available, which is helpful for reference and unhelpful when a report quietly uses the wrong one.

  • The most current released version is the OWASP Top 10 2025. The 2021 and 2017 editions remain published for reference, which is why a report can appear current while working from a superseded list.
  • Software supply chain failures now sit at A03 in the 2025 edition. That is a category most web audits historically treated as a footnote, and it reflects how applications are actually built: assembled from dependencies rather than written from scratch.
  • Mishandling of exceptional conditions appears at A10 in the current edition, and security logging and alerting failures at A09. Both concern what happens when something goes wrong, which is the part of an application least likely to have been tested.
  • The practical implication is simple. Ask which edition a proposed audit works against. If the answer is 2021, the findings will be genuine and the coverage will reflect a different set of priorities from the ones OWASP now publishes.
Ask us to audit against the current list
How we approach it

Four things that separate a web audit from a scan report.

Automated tools are genuinely useful and they cover a specific part of the current list well. The categories they cannot reach are the ones that produce the incidents, which is why the method matters more than the tooling.

We test access control with real accounts at every role

A01 remains the first category, and finding it requires acting as one user and attempting to reach another user data and functions. That needs test accounts at each privilege level and somebody who understands what the application is supposed to permit. It is the least automatable part of the work and consistently the most productive.

We treat the dependency list as a finding in itself

Software supply chain failures sit at A03 in the current edition. The first question is not whether a vulnerable package is present, it is whether anybody can produce the list. Where the answer is no, that is the finding, because a dependency inventory nobody maintains is a vulnerability nobody will notice being introduced.

We start by finding the applications you forgot

A scope defined from memory misses the campaign microsite an agency built, the staging environment still resolving, and the API somebody exposed for one integration. External attack surface discovery before scoping consistently adds applications to the list, and the forgotten ones are reliably in worse condition than the ones you remembered.

We retest, because a finding is not closed until it is verified

A report that ends at delivery leaves the most important question unanswered, which is whether the fix worked. Retesting is part of the engagement rather than an option, and it regularly finds that a change addressed the specific example given rather than the underlying issue across the application.

Where this matters most

Six UAE situations where a web audit is the right first step.

The trigger is usually external: a customer requirement, a regulator question, a payment provider, or an incident somebody else had. Occasionally it is a launch, which is the best time to do it.

A business taking payments or personal data through its site

Cryptographic failures at A04 and broken access control at A01 are directly the categories that expose customer data, and both are exactly what a data protection obligation asks about. Where card data is involved, an application security position is also part of what a payment obligation expects rather than a nice addition to it.

An organisation whose customers now ask about application security

Enterprise procurement increasingly includes web application security questions, and a documented audit against the current OWASP Top 10 with retested findings is a far stronger answer than a scan report. It also answers the next customer question at a fraction of the cost, because the work is already done.

A group with applications built by several agencies over years

Different builders, different frameworks, different levels of care, and nobody with a complete picture. Security misconfiguration at A02 and software supply chain failures at A03 are the categories that dominate in this profile, because each application carries the assumptions of whoever built it and the dependencies they happened to choose.

A regulated firm with a customer-facing portal

Authentication failures at A07 and security logging and alerting failures at A09 matter most here, because a regulator will ask both whether access is properly controlled and whether you would know if it were abused. The second question is the one organisations are least prepared for.

An organisation about to launch something

The cheapest time to find insecure design at A06 is before it ships, because the finding concerns decisions rather than defects and changing a decision after launch is expensive. An audit during development, rather than as a gate before go-live, is where that category is actually addressable.

An institution with more public sites than anybody realised

Faculties, campaigns, events and student bodies produce web properties continuously, frequently on infrastructure the central team never sees. Discovery before scoping is essential here, and the forgotten sites are consistently where security misconfiguration and unpatched dependencies are worst.

Three positions

How UAE organisations check their web applications.

The middle column is common and produces a comforting report. An automated scan finds real issues and structurally cannot find the first, third or sixth categories on the current list.
Injection and common flaws found
Audited against the current Top 10Yes
Automated scanning onlyYes
Never testedNo
Access control tested across roles
Audited against the current Top 10Yes
Automated scanning onlyRarely
Never testedNo
Insecure design identified
Audited against the current Top 10Yes
Automated scanning onlyNo
Never testedNo
Dependency and supply chain reviewed
Audited against the current Top 10Yes
Automated scanning onlyPartly
Never testedNo
Platform configuration reviewed
Audited against the current Top 10Yes
Automated scanning onlySometimes
Never testedNo
Logging and alerting assessed
Audited against the current Top 10Yes
Automated scanning onlyNo
Never testedNo
Failure paths examined
Audited against the current Top 10Yes
Automated scanning onlyNo
Never testedNo
Findings verified after fix
Audited against the current Top 10Yes
Automated scanning onlyNo
Never testedNot applicable
Against the current 2025 edition
Audited against the current Top 10Yes
Automated scanning onlyDepends on the tool
Never testedNot applicable
Report a customer would accept
Audited against the current Top 10Yes
Automated scanning onlySometimes
Never testedNo
Feature
Audited against the current Top 10
Automated scanning only
Never tested
Injection and common flaws found
YesYesNo
Access control tested across roles
YesRarelyNo
Insecure design identified
YesNoNo
Dependency and supply chain reviewed
YesPartlyNo
Platform configuration reviewed
YesSometimesNo
Logging and alerting assessed
YesNoNo
Failure paths examined
YesNoNo
Findings verified after fix
YesNoNot applicable
Against the current 2025 edition
YesDepends on the toolNot applicable
Report a customer would accept
YesSometimesNo
The current list

OWASP Top 10 2025, and what each means for a UAE web estate.

Category codes and names as published by OWASP. The right hand column is what we most commonly find in this category, which is ours rather than OWASP.
CategoryNameWhat we most often find
A01:2025Broken Access ControlObject identifiers in URLs that are not checked against the signed-in user
A02:2025Security MisconfigurationVerbose error pages, default accounts, and hardening never applied to the platform
A03:2025Software Supply Chain FailuresNobody can produce the dependency list, and nothing watches for changes in it
A04:2025Cryptographic FailuresSensitive fields stored or transmitted without the protection anybody assumed was there
A05:2025InjectionParameterisation applied in most places, and one legacy query where it was not
A06:2025Insecure DesignA workflow that trusts a client-supplied value it should never have trusted
A07:2025Authentication FailuresPassword reset flows, session handling and rate limiting on the login path
A08:2025Software or Data Integrity FailuresA deployment pipeline that would not detect an unauthorised change
A09:2025Security Logging and Alerting FailuresApplication events logged nowhere anybody monitors
A10:2025Mishandling of Exceptional ConditionsFailure paths that reveal internal detail or leave the application in an unexpected state
How an engagement runs

Five steps, and retest is included rather than optional.

Typically two to five weeks depending on the number and complexity of applications, plus a retest window after remediation.
  1. 1

    Discover what actually exists

    Before scoping from a list somebody supplies, external discovery to find the applications that list does not include. Campaign sites, staging environments still resolving, APIs exposed for a single integration. The forgotten ones are reliably in worse condition, which makes them the wrong things to leave out.

  2. 2

    Scope against the current Top 10 and gather access

    Test accounts at each role, because access control at A01 cannot be tested without them. The dependency manifest for A03, the deployment configuration for A02 and A08, and any design documentation for A06. What we can see determines what we can find, and the difference is substantial.

  3. 3

    Test across all ten categories, not only the automatable ones

    Automated coverage where it is effective, then manual work on access control, design, authentication flows, integrity of the deployment pipeline, logging and the failure paths. The categories a tool cannot reach are the ones that produce incidents, so they get proportionally more of the time.

  4. 4

    Report against the categories, with reproduction and impact

    Each finding mapped to its OWASP category, with steps to reproduce, the actual impact rather than a generic severity, and a specific remediation. A finding somebody cannot reproduce does not get fixed, and a severity without a business impact does not get prioritised.

  5. 5

    Retest and confirm the fix reached the pipeline

    Verification that each finding is genuinely closed, which regularly reveals that the specific example was fixed and the underlying pattern was not. We also check the fix exists in the source and the pipeline rather than only in the running instance, since otherwise the next deployment reintroduces it.

Straight answers

What organisations ask about web application audits.

The OWASP Top 10 2025, which OWASP publishes as the most current released version. The 2021 and 2017 editions remain available for reference, which is worth knowing because a report can look current while working from a superseded list. Ask any provider which edition they use, and expect a specific answer.

A01 broken access control, A02 security misconfiguration, A03 software supply chain failures, A04 cryptographic failures, A05 injection, A06 insecure design, A07 authentication failures, A08 software or data integrity failures, A09 security logging and alerting failures, and A10 mishandling of exceptional conditions.

It covers part of the list well and structurally cannot reach the rest. Broken access control at A01 requires acting as one user and attempting to reach another data. Insecure design at A06 concerns decisions made before code was written. Software supply chain failures at A03 require the dependency picture. Those three are among the most consequential categories and none of them is a scanning problem.

Because it reflects how applications are now built. A modern web application is assembled from dependencies, each of which has its own dependencies, and the resulting tree is frequently larger than the code anybody in the organisation wrote. Software supply chain failures at A03 in the 2025 edition acknowledges that the assembled parts are as much the application as the code around them.

Yes, and it matters. Security misconfiguration sits at A02, and a large share of what falls into that category lives in the deployment rather than the source: default accounts, verbose errors, unnecessary features enabled, absent hardening, missing headers. An audit scoped only to application code systematically misses the second-ranked category.

They should be in scope, and they frequently have weaker access control than the web interface in front of them, because the interface is what people test. The same categories apply, and A01 broken access control in particular tends to be more exposed at the API layer where object identifiers are handled directly.

For meaningful access control testing, yes, at each role that exists. The central question in A01 is whether a user can reach data or functions belonging to another user or to an administrator, and answering it requires being able to act as each. An audit run without authenticated access covers the public surface and leaves the most productive category untested.

Either, with different constraints. A representative test environment allows more thorough testing without risk to live data or availability. Production testing is possible and is conducted more carefully, with agreed windows and a defined stop condition. What matters most is that the environment tested resembles the one that serves customers.

Reproducible, with the actual impact stated rather than a generic severity label, and a specific remediation rather than a reference to a category. A finding that a developer cannot reproduce will not be fixed, and a severity with no business impact behind it will not be prioritised. Both failures are common in scan-derived reports.

Yes, and we regard it as part of the engagement rather than an add-on. Verification frequently reveals that the specific example given was fixed while the underlying pattern remains elsewhere in the application. It also confirms the fix reached the source and the deployment pipeline rather than only the running instance.

Applications change continuously, so the honest answer is that a point-in-time audit describes a point in time. Annually is a reasonable baseline for a stable application, more often where development is active, and always after a significant change to authentication, authorisation or the deployment pipeline. Dependency monitoring should be continuous rather than periodic.

They overlap and answer different questions. A web application audit works systematically through the OWASP categories to establish the security position of the application. A penetration test attempts to achieve an objective through whatever route exists, which may include the application, the network, the people or all three. Most organisations need the audit first and the test afterwards.

Substantially, particularly where the questionnaire asks about application security testing. A documented audit against the current OWASP Top 10 with reproduced findings and verified remediation is a stronger answer than a scan report, and it answers the next questionnaire at a fraction of the effort because the underlying work already exists.

That is the common case, and it shapes the remediation conversation rather than the audit. Findings go to whoever can fix them, and the useful additional output is a clear statement of which findings are in the application, which are in the deployment, and which are in the dependency set, since those three frequently have different owners.

They remain published and they remain useful as reference, which is exactly why it is worth asking which edition an audit works against. OWASP keeps the 2021 and 2017 editions available alongside the current 2025 list. A tool or a report built around an earlier edition produces genuine findings against a set of priorities that has since been revised, and the categories that moved are the ones you would most want covered.

Separate them explicitly in the report, because they have different owners and different remediation routes. Findings in your own code go to your development team or your agency. Findings in the platform configuration go to whoever operates the hosting. Findings in dependencies, which sit at A03 in the current list, go to whoever controls the build, and the remediation is usually a version change rather than a code change. Reporting them as one undifferentiated list is why remediation stalls.

We scope per engagement, driven by the number of applications, whether authenticated areas and APIs are included, and how much of the estate discovery finds that you did not have on the list. The discovery step comes first and is quick, because it regularly changes the scope before anybody commits to it.
Scoping the audit

Fifteen questions that determine whether the audit is useful.

The first group is what is being tested, the second is what access we have, and the third is what happens to the findings, which is where most web audits stop being valuable.

Scope

  • Which applications are in scope?
    Including the ones marketing built.
  • Do you know all your public sites?
    External discovery usually finds more.
  • Is the platform in scope as well as the code?
    A02 lives in the deployment.
  • Are the APIs in scope?
    They frequently have weaker access control.
  • Is there an authenticated area?
    A01 findings are almost all behind login.

Access

  • Will we get test accounts at each role?
    Access control testing needs several.
  • Is there a test environment?
    Or are we testing production carefully.
  • Can we see the dependency manifest?
    A03 is far faster with it.
  • Can we see the deployment configuration?
    A02 and A08 depend on it.
  • Is there any design documentation?
    A06 cannot be found without context.

Afterwards

  • Who fixes the findings?
    Internal team, or the agency who built it.
  • Is there a retest included?
    A finding is not closed until it is verified.
  • Does the fix reach the pipeline?
    Or only the running instance.
  • Will dependencies be watched from now on?
    A03 is a continuous problem.
  • When is the next audit?
    Applications change continuously.
Related reading

The pages around this one.

Penetration testing

Objective-driven testing across the whole estate rather than systematically through one application.

Learn more

Defender EASM

Finding the applications and sites that were never on anybody list.

Learn more

Vulnerability assessment

The wider scanning programme that runs between audits.

Learn more
Next step

Ask whoever built your site for the dependency list. Then see how long it takes.

Software supply chain failures sit at third in the current OWASP Top 10. If nobody can produce the list quickly, that is already a finding, and it is the one that determines how much else the audit is likely to surface.

Book a web application auditCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Penetration Testing

Black, grey, and white-box penetration testing

Learn more

Defender EASM

Discovers internet-facing assets you never registered

Learn more

Vulnerability Assessment

Continuous vulnerability scanning and remediation

Learn more

VAPT Testing

CREST-certified vulnerability assessment and penetration testing

Learn more

IT Audit Services Dubai

Assessment, technical test or certification, scoped properly

Learn more

Managed WordPress

Hardened WordPress hosting and care

Learn more

Cybersecurity Audit

Security assessment and compliance audit

Learn more

PCI DSS Compliance UAE

Scope reduction first, then the controls that remain

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy