Key takeaways
- A web application pentest produces a known set of hostile requests against a known target inside a known window, which makes it the cheapest detection rehearsal available to a security team.
- Authorisation abuse is the hardest class to see, because a successful cross-tenant read returns the same status code as a legitimate one and only the contents of the log record separate them.
- An access log carrying a source address, a path and a status code cannot support a rule about who did what to whose data. The requester identity, the object owner and the authorisation decision have to be in the record.
- Agree the deconfliction details before the test starts: tester source addresses, the test window and a shared timestamp reference, so a missed alert can be told apart from a suppressed one.
- Score the engagement twice, once on findings and once on what the monitoring saw. The second scorecard costs nothing extra and it often produces the longer list of work.
Every pentest is a free detection rehearsal
You are already paying someone to attack your application on a schedule you agreed. The findings are the product you bought. The traffic is a second product: a set of hostile requests, aimed at a known target, inside a known window, produced by an operator who will write down exactly what was sent and when. No other purchase gives your monitoring that combination.
That makes the engagement worth reading twice. A web application pentest answers whether the application can be broken. Read the same week of traffic from the defensive side and it answers a second question you cannot otherwise test without staging an incident: if someone did this to you next month, would anyone notice, and how long would it take? OWASP lists security logging and monitoring failures in its 2021 top ten because the answer is so often no.
None of this needs a second budget line or a separate exercise. It needs a decision, taken before the test starts, that the monitoring result is one of the outputs.
The five things a tester does that should reach someone
Web application testing is not quiet. Enumeration, credential attacks, injection probing and file upload abuse all generate volume, malformed input or unusual response codes, and each has an observable shape. The table below is the short list to check first, because every row maps to a rule that is easy to assume already exists.
The right-hand column is the part worth reading twice. In four of the five rows the request reaches the application and the application answers it correctly. What fails is the record, not the control. What a web application pentest covers sets out the classes of finding an engagement produces; this is the same list written as the traces those findings leave behind.
The sequence below is the general case, and the uncomfortable part of it is the last step. Four parties are involved, and the only one guaranteed to know what happened is the tester.
- Tester → Your application
Reads forty order records in ninety seconds
One authenticated session, identifiers walked in order
- Your application
Checks authentication, never checks ownership
The decision is made and then discarded
- Your application → Log pipeline
Writes an access line: address, path, status 200
No requester identity, no object owner
- Log pipeline → Analyst on duty
Presents it beside ordinary customer traffic
Same status code, same shape, nothing to sort on
- Analyst on duty → Tester
Learns of the reads from the test report
Weeks after the requests were served
| Tester activity | What reaches the log | Why it is missed |
|---|---|---|
| Credential stuffing at the login form | A burst of failed authentications | Thresholds count per account, so a spray across many accounts stays under all of them |
| Forced browsing for hidden routes | A run of 404 and 403 responses | Error statuses are sampled out or dropped at the edge before they reach the platform |
| Object identifier tampering | Successful 200 responses | Nothing separates them from a customer opening their own record |
| Injection probing in a search field | Long parameters holding quotes and comments | Query strings are stripped from the line for privacy reasons and never restored |
| Upload of an unexpected file type | One POST and a 201 | The filename and declared content type are not fields in the record |
A log line without identity cannot support a rule
The default application access log is a web server format: an address, a timestamp, a method, a path, a status code and a byte count. That format was designed to count traffic. It cannot say who made the request, which object was touched, or whether the application decided to allow it, and no detection rule can test a field that was never written.
The example below is one request rendered twice, first as a standard access line and then as a record built for security use. Both describe the same successful read. Only the second carries enough to compare the requesting tenant against the owning tenant, which is the comparison that turns an object level authorisation flaw into an alert rather than a report finding. NIST's guide to computer security log management and the OWASP logging cheat sheet both set out the field list. Getting the application to emit it is the work.
The same holds one tier down, where the log is often the only place a request is visible at all because there is no page render to fall back on. If the application and its API surface are tested in the same engagement, ask for the monitoring result on both.
Who asked
Authenticated user or service identity, not just an address
What was asked for
Method, route template and the identifier of the object
Who owns it
The tenant or user the object belongs to, from the data layer
What was decided
Allow or deny, and the rule that made the call
How to find it again
Request identifier that survives across services and hosts
| Field | Standard access line | Record you can alert on |
|---|---|---|
| Identity | Absent: 203.0.113.10 only | user=u_8814 role=agent tenant=t_207 |
| Object | GET /orders/1043 | route=/orders/:id object=1043 owner=t_119 |
| Decision | Inferred from status 200 | authz=allow rule=order.read.tenant |
| Correlation | None | req=6f2ac31, spans gateway, service and database |
Authorisation abuse is the class you will miss
Injection probing announces itself. A credential attack announces itself eventually. Authorisation abuse does neither, because a successful attack on object level authorisation is a well formed request from an authenticated session that returns a 200 with a body in it. Sorted by status code, it sits in the same bucket as everything a paying customer did that morning.
OWASP ranks broken object level authorisation first in its API list, and the reason it is hard to detect is the same reason it is common: the control is missing rather than bypassed, so there is no error to record. The detection has to be built from the difference between two facts in one record, the identity that asked and the tenant that owns the object. Testing authorisation role by role is how the flaw gets found. Emitting the owner beside the requester is how it would have been seen.
There is a coarser signal available before any of that lands: velocity across identifiers. One session reading forty order records in ninety seconds is not a customer, whatever each individual response code says on its own. That rule fires on internal tooling and on legitimate exports, which is an argument for tuning it against a week of real traffic rather than an argument for skipping it.
Score the test twice, and agree the ground rules first
Deconfliction is normally framed as a safety measure, so the defenders do not spend a night chasing a paid tester. It is also what makes the monitoring result readable. Record the tester's source addresses, the test window and a timestamp reference both sides will use, then keep a running note of what fired and when. Without that note, a missing alert and a suppressed alert look identical afterwards.
Ask the tester for a timeline of significant actions with timestamps and compare it against what your platform produced. Each line lands in one of four places, and they lead to different work with different owners. Only one of them costs real money. This is the same comparison a purple team engagement runs deliberately and at much greater coordination cost, and the rules that come out of it need the same upkeep afterwards, which detection decay covers.
Write the technique names against a shared vocabulary rather than local shorthand. MITRE's exploit public-facing application technique is a blunt label for a lot of what happens in a web test, but a shared reference is what lets this year's scorecard be compared with next year's.
| Comparison result | What it means | Who owns the fix |
|---|---|---|
| An alert fired inside the window | Rule and data both work. Record the time to detect as a baseline. | Nobody. Keep the rule under test |
| The data was there, nothing fired | A detection engineering gap, and the cheapest class to close | Detection team, this quarter |
| The data was not there | An instrumentation gap in the application itself | Product engineering, in a release |
| An alert fired on the wrong thing | A rule keyed to the tester's address rather than the behaviour | Detection team, before the next test |
Sort the gaps before writing a single rule
A first scorecard can produce more gaps than a team will close in a quarter, and closing them in the order they were found is the wrong order. Two questions sort the list: what would it cost the business if this were abused for real, and what does it take to see it at all. The second question is where the surprises are, because instrumenting an application to emit an authorisation decision is a code change with an owner and a release date, while writing a rule over data you already collect is an afternoon.
The grid below sorts on those two questions. The bottom right cell is the one teams skip: writing down that you have chosen not to detect something, with the reason and a date, is a real output. It stops the same gap being rediscovered at the next test and presented as new.
One caution on scope. If the answer to most rows is that nothing was collected, the fix is an engineering programme rather than a detection one, and booking another application test or an assumed breach exercise before that work lands will produce the same scorecard a second time.
Damage if abused
Write the rule now
Real harm, data already collected. Nothing on the list competes.
Fund the instrumentation
No rule is possible until the application emits the field. Needs a release.
Dashboard, do not alert
Keep it visible for hunting. An alert here trains people to ignore alerts.
Record the decision
Write down that you chose not to detect it, and why, with a date.
Cost to see it
What this means for teams in Dubai and Abu Dhabi
Regulated entities in the UAE are already required to log security events and to have someone review them, and the requirement is written into more than one regime. Licensed financial institutions answer to the Central Bank of the UAE. Dubai government entities and the suppliers who serve them work to the standard published by the Dubai Electronic Security Centre. Abu Dhabi healthcare providers work to ADHICS, and the Information Assurance Standard published by NESA applies federally. Each of them asks for security event logging. None of them can tell you whether your own application emits enough for a rule to fire on it.
That is the gap a test closes cheaply. A free zone entity in Dubai Silicon Oasis and a mainland company in Abu Dhabi may sit under different contractual obligations, but both are asked to produce evidence of monitoring rather than a description of it, and a dated scorecard from a penetration testing engagement is evidence in a form an assessor can read. Where the application is hosted or operated outside the country, settle before the test which side holds the logs and for how long, because a provider's default retention may be shorter than the window a UAE regulator's assessor asks about.
Frequently asked questions
Should we tell our security operations team that a web application pentest is running?
Yes, for a standard penetration test. The engagement exists to find flaws in the application, and an unwarned team spends the week chasing traffic you paid for. Share the test window and the tester's source addresses, keep a note of what fired, and compare the two timelines afterwards. If you specifically want to know whether the team notices without warning, that is a Red Team or adversary simulation objective and it should be scoped as one.
What is the difference between this and a purple team exercise?
A purple team exercise is built around detection: techniques are chosen for what they should trigger, the defenders watch live, and rules get written and retested in the room. Reading the detection result from a penetration test is opportunistic by comparison, using traffic that was going to happen anyway. It costs almost nothing extra, and it is a sound way to find out whether a purple team engagement is worth funding.
Which application logs matter most during a web application pentest?
Authentication events, authorisation decisions, and every request that reads or writes an object belonging to a specific user or tenant. The first two are the cheapest to add. The third decides whether object level authorisation abuse is visible at all, because those requests succeed and return ordinary status codes.
How long do we need to keep the logs for this comparison to work?
Long enough to cover the test window plus the time it takes to receive and read the report, which is a matter of weeks rather than days. Retention shorter than that gap means the tester's timeline arrives after the evidence has expired and the comparison cannot be made at all. Agree the retention period during scoping, alongside the test dates.
