Key takeaways
- The unit of scope is the role and the function, not the page: an application with five roles takes longer to test than a larger one with two.
- A test run with a single set of credentials cannot find a horizontal authorisation flaw, because there is no second account to reach across to.
- The OWASP Top 10 is a list of risk categories to cover, not a test plan; the testing guide beneath it is the document that describes the work.
- Roughly two days go on enumeration, the middle of the engagement on authorisation and logic, and the last two days on the report.
- The test says nothing about the network under the application, the mobile client in front of it, or whether your monitoring noticed any of it.
What the test reaches
A web application pentest is an authorised, manual assessment of an application and the logic behind it, run to find the places where somebody can do something the application was built to stop. A tester works the application from the position of a real user, chains what they find, and writes each step down so a developer can reproduce it. Tooling is used for coverage. Nothing is reported on tool output alone, because a scanner reports conditions and a test reports consequences.
The unit of scope is not the page. It is the role, and the set of functions each role can reach. An application with five roles and a two-step approval flow takes longer to test than a larger one with two roles and no approvals, because the interesting question is what happens at the boundaries between them. That is why a web application pentest is quoted against a role matrix and a function list rather than a URL count, and why the OWASP Web Security Testing Guide is organised by test category rather than by page.
The classes a tool finds, and the classes it cannot
Two kinds of finding come out of a web application test and they cost completely different amounts to produce. The first is a condition: a missing header, an outdated library, a weak TLS configuration. It has a signature, a tool matches it, and the evidence is the response itself. The second is a consequence: changing one identifier in a request returns another customer's invoice. Nothing matched a pattern there. Somebody held two accounts, worked out what the identifier meant, and tried it.
The OWASP Top 10 names both kinds together, which is why quoting it back does not describe a test. It is a list of risk categories to cover, and the 2021 edition puts broken access control first. A proposal that says it tests for the OWASP Top 10 has told you the ground it covers and nothing about how far into that ground it goes, which is the same distinction as paying for a test rather than a scan. The classes below are ordered by what it costs to produce each one.
| Finding class | What surfaces it | What proving it costs |
|---|---|---|
| Missing header, outdated component, weak TLS | Automated scanning, reliably | Minutes. The evidence is the response itself |
| Reflected and stored cross-site scripting | A scan finds candidates, a person confirms them | Hours. Context and filter behaviour decide exploitability |
| SQL, command and template injection | A scan finds the direct cases | Hours to a day where the input is reached indirectly |
| Object level authorisation, one account reading another's records | Only a person, holding two accounts at the same level | A day or more. Every object type, per role |
| Function level authorisation, a role calling an action above it | Only a person, working from the function list | A day or more. Every role against every action |
| Business logic: skipped approval, replayed request, negative quantity | Only a person who understands what the application is for | The largest single block of the engagement |
Why the test needs credentials for every role
Authorisation flaws run in two directions. Horizontal is one account reaching another account's data at the same privilege level: same role, different owner. Vertical is an account reaching a function above its level, such as a standard user calling an administrative action. A test performed with a single set of credentials cannot find a horizontal flaw at all, because there is no second account to reach across to, and it can only guess at the vertical ones.
The request for credentials is therefore not administrative overhead. It decides which half of the finding list is reachable at all, and two accounts per role is the working minimum. Where roles are withheld, the report should name the tests that could not be run instead of presenting a shorter list as a cleaner result. The same reasoning carries through to the API pentest underneath a single page application, where the authorisation boundary is the endpoint rather than the screen, and the OWASP Application Security Verification Standard states access control requirements at that level rather than at the interface.
Below is the form a finding of this class takes in a report. It is illustrative rather than drawn from an engagement, and it is short on purpose: what carries the weight is the reproduction path and the named boundary that failed.
| Field | Example entry |
|---|---|
| Title | Invoice records readable across tenants by identifier substitution |
| Roles used | Two standard accounts, one in tenant A and one in tenant B, both supplied at scoping |
| Steps | As tenant A, open an owned invoice and note the identifier format in the request; repeat the same request with an identifier belonging to tenant B |
| Result | The full invoice document is returned, including line items and the counterparty name |
| Boundary that failed | Ownership is checked when the list is built and not when a single record is fetched |
| Severity | High. No privilege beyond a valid account is required and identifiers are sequential |
| Fix and owner | Enforce the ownership predicate in the data access layer, not the controller. Named application owner |
How the time is actually spent
A two-week test is not ten days of exploitation. The first two days go on enumeration and reading the application: walking every function as every role, mapping the requests that sit behind the screens, and building the role matrix the rest of the work is measured against. The middle of the engagement is authorisation and logic testing, function by function, and that part cannot be shortened without narrowing what the test is able to claim afterwards. The last two days are reporting, because the report is the deliverable and a finding nobody can reproduce is not a finding.
That shape is why scoping decides cost more than any other decision on the engagement, and why an asset list that arrives late compresses the phase you would least like compressed. How to scope a penetration test covers that decision on its own terms. NIST SP 800-115 sets out the same division as planning, execution and post-execution, which is a useful thing to cite in a procurement document when somebody asks why reporting time is quoted separately from testing time.
What the test does not tell you
A web application pentest is bounded by the application. It does not test the network the application sits on, the segmentation between that network and anything else, or the hosts underneath it: that is an infrastructure pentest, with a separate scope and separate access requirements. It does not test the mobile client speaking to the same backend, and it stops at the point where a foothold inside the application would become a route into an internal system.
It also does not answer whether anybody saw it. The test is announced, run from named source addresses, and often allowlisted so that the traffic gets through, which is the correct choice for coverage and removes any conclusion about detection. If the question is whether your monitoring would notice, that is a Red Team engagement or a purple team session, and it is a different purchase with a different output. The last boundary is time: a report describes the application on the dates it was tested, so a release two weeks later is untested, which is the argument for tying testing to the release cycle rather than to the calendar.
What a supervisor in Dubai or Abu Dhabi reads in a web app report
Four regimes name security testing for organisations operating in the UAE: the Central Bank for licensed financial institutions, the Dubai Electronic Security Center for Dubai government entities and the suppliers who serve them, ADHICS for healthcare providers in Abu Dhabi, and the federal Information Assurance Standards published by NESA. Read the one that binds you rather than a summary of it, because what each asks an entity to hold differs. For a web application the practical overlap is narrow and specific. Each expects testing carried out by a party independent of the people who built the application, findings tracked to closure against a named owner, and evidence that a fix was verified rather than asserted.
Two things about this market change how the test is scoped rather than how it is run. Where an application reaches a partner or a government integration, the boundary of the test is not the boundary of the login page, and supplier connections are explicitly in scope under DESC, so an asset list drawn from the public site alone will miss them. Whether the entity is licensed in a free zone or on the mainland changes who supervises it and what the contract requires, not what the testing has to reach. Our summary of what each UAE regulator asks for sets out where those obligations sit. The report that answers a supervisor in either emirate is the same one that is useful internally: scope, written authorisation, findings with reproduction steps, named owners and a dated retest.
Frequently asked questions
What does a web application pentest actually test?
Authentication and session handling, object and function level authorisation across every role, the business logic the application assumes but does not enforce, the injection and client-side classes in the OWASP Top 10, file and data handling, and configuration. The parts that take the longest are authorisation and business logic, because both require a person reasoning about what the application is for. Everything with a signature is found early and cheaply.
Why does a web application pentest need credentials for every role?
Because a horizontal authorisation flaw is one account reading another account's data at the same privilege level, and a tester holding one account has nothing to reach across to. Vertical flaws need the higher role as well, so the tester can confirm what the action should have returned. Two accounts per role is the working minimum, and any role that is withheld should appear in the report as a test that could not be run.
How long does a web application pentest take?
One to three weeks including reporting for most applications, driven by the number of roles and distinct functions rather than by page count. A small application with five roles and an approval workflow takes longer than a large one with two roles and none. Reporting is a fixed block at the end and is quoted separately, because the report is what the engagement produces.
Is the OWASP Top 10 enough to scope a test against?
It is enough to describe the ground, not the depth. The Top 10 is a list of risk categories, so a proposal written against it tells you which classes are in view and nothing about how many roles are tested or whether every object type is checked. Scope against a role matrix and a function list, and use the OWASP Web Security Testing Guide, which is written as test cases rather than as categories.
