OWASP A01, A03, A05 and A09: the SIEM signals a web app pentest produces

What the detection side of a web app pentest must prove

A web application pentest is not complete when the last finding is written. The report must be matched against what your security controls actually saw. If a tester replayed a SQL injection payload thirty times and your WAF has no corresponding entries, the control is not working, and the pentest has uncovered a detection gap as significant as the injection itself.

OWASP publishes ten risk categories in its Top 10. Four of them, A01, A03, A05 and A09, are directly observable in logs: they produce specific entries, fire specific SIEM rules and generate alerts when thresholds are set correctly. This article names those signals and shows the log patterns your detection team should expect. For the broader question of which controls fire across all phases, see what your monitoring should catch during a web app pentest. The focus here is the four classes that produce the most useful detection signals.

A01: access control failures and IDOR in the access log

Broken Access Control is OWASP's highest-ranked risk category. The class includes insecure direct object references, known as IDOR, where an application uses a predictable identifier to serve protected resources and does not check whether the requesting user is entitled to them. A tester probing for IDOR changes one field in a request, an account ID, an order number or an invoice reference, then measures whether the server returns another user's data with a 200 status code.

The access log pattern is distinct. A single authenticated session cycles through a sequence of numeric IDs without any other page navigation between them. That is not normal user behaviour. A SIEM rule that fires when one session generates more than ten 200-response GETs against a parameterised endpoint within five minutes, without any matching page load in between, will catch the pattern and distinguish it from a user browsing their own records. The article on testing authorisation role by role explains how to construct those test cases; the SIEM threshold rule below is the detection counterpart to that work.

Define the threshold against your application's legitimate access pattern, not against a generic baseline. An API that serves account records to a service account may legitimately request fifty objects in rapid succession; a browser-based application almost never does. A threshold calibrated to the application reduces false positives and means the alert is worth acting on when it fires.

RULE idor_probe
  source: web_access_log
  filter: http_status = 200
         AND path ~ /api/(accounts|orders|invoices)/[0-9]+
  group_by: session_id
  condition: count > 10 within 5m
            AND distinct(resource_id) > 5
  alert: "IDOR probe: {session_id} accessed {distinct_count} distinct resource IDs"

A03: SQL injection and XSS in WAF and web server logs

SQL injection appears in web server logs and WAF logs before it reaches the database. The raw HTTP request carries the payload in a query parameter, a form field, or a path segment, and the web server records it. A WAF set to monitor mode captures and labels the payload without blocking it; that is the standard configuration during a pentest, so the tester can probe while the detection stack records the full attempt.

XSS payloads leave a different entry. A stored XSS payload submitted through a form is logged at write time, and the script tag or encoded equivalent appears in the access log at the POST request. A reflected XSS attempt appears as an unusual parameter value in a GET request, often URL-encoded. Both are distinguishable from ordinary traffic if the WAF rule set flags script injection patterns, not only known-bad signatures. Reviewing both injection types as a pair tells you whether WAF coverage extends past SQL to the browser-side classes as well.

192.168.1.42 - alice [10/Nov/2026:09:14:22 +0000] "GET /search?q=1'+OR+'1'='1 HTTP/1.1" 200 1452

[10/Nov/2026 09:15:03] RULE_ID=941100 SEVERITY=CRITICAL
  URI=/comments?reply=%3Cscript%3Ealert(1)%3C%2Fscript%3E
  CLIENT=192.168.1.42 HTTP_METHOD=GET RESPONSE=400
  MSG="XSS Attack Detected via libinjection"

A05: security misconfiguration and what logs record

Security misconfiguration covers missing security headers, default credentials left active, unnecessary services exposed, and verbose error messages that disclose stack traces. A pentest finds these in the application response, but detection tools find them differently: they appear as error codes that a correctly configured application would not return, and as the absence of headers a well-configured one always sets.

A SIEM cannot read a response header the way a browser does, but it can read application logs that record response codes. An endpoint that returns 200 but never sets a Content-Security-Policy header is not visible from the SIEM; that check belongs in a vulnerability scanner or an API pentest where headers are read actively. What a SIEM sees from A05 is the 500-level responses that verbose error handling returns: a stack trace on a production endpoint is a configuration failure, and a cluster of server errors from a single IP during a pentest window is a signal worth alerting on. If those 500s do not appear in the SIEM, the application is not forwarding error events, which is itself an A09 finding discussed in the next section.

Set the alert threshold below the noise floor of your legitimate error rate. An application that rarely errors should alert on three consecutive 500s from one IP within two minutes. The threshold is not universal: it is derived from the application's observed behaviour during normal operation and reviewed before each engagement.

A09: when the logging failure is itself the finding

A09 Insufficient Logging and Monitoring is the only OWASP category that is itself a detection failure. The others describe vulnerabilities in the application; A09 describes a gap in your ability to see those vulnerabilities being exploited. OWASP defines the class as the failure to detect, escalate or respond to active breaches, and names the absence of audit trails for login failures, high-value transactions and access control exceptions as the primary indicators. The OWASP Web Security Testing Guide section on logging and monitoring provides the test cases your detection team should run alongside the pentest.

During a web application pentest, A09 findings surface when the tester's actions do not appear in logs. A series of failed authentication attempts that generates no SIEM alert, an administrative function call with no audit record, or a privilege escalation with no corresponding log entry are all A09 findings, not just application configuration items. The OWASP A09 guidance lists the minimum events every application should log: authentication events, access control failures, server-side validation failures and high-value transactions. If the application misses any of these, the SIEM cannot compensate because there is no event to ingest.

The check is simple in practice: run the pentest, then query your SIEM for the specific actions the tester executed. A finding logged as unauthenticated access to an administrative endpoint should appear in the application audit log within minutes. If it does not, the application is not generating the event the SIEM needs. The fix sits with the application developer, not with the SIEM rule writer. Business logic attacks have a parallel problem: the article on testing business logic flaws covers the test cases, and each one that does not produce an audit entry is an A09 finding alongside the business logic flaw itself.

Converting pentest findings into permanent detection rules

The gap list from the pentest feeds directly into detection engineering work. For each finding that your SIEM did not log, the first step is to determine whether the application generates an event at all. If the application logs the action but the SIEM has no correlation rule, write a rule against the existing field and set a threshold calibrated to the application's normal traffic. If the application does not log the action, raise a development task to add the event before the next engagement. Distinguish the two: a missing rule is a one-day fix; a missing application event requires a code change, testing and a release cycle.

Two exercises follow the detection gap review. A purple team engagement replays each finding as an adversary technique, with your detection team watching in real time, so the SIEM rule is not just written but confirmed to fire before the engagement closes. An assumed-breach exercise starts from an already-compromised account and tests whether lateral movement through the application generates observable signals at every hop. Both are a natural follow-on once a web app pentest surfaces detection gaps across the four OWASP classes covered here.

Export the SIEM queries that fired during the pentest window and convert them to permanent rules before the engagement closes. Those queries describe exactly the patterns the tester used, they are already calibrated to your application, and they give your security operations team the evidence to monitor for the same attack patterns in production traffic. A pentest that improves your detection estate is worth more than one that produces only a vulnerability list.

Web application pentest detection requirements in the UAE

In the UAE, the requirement to maintain audit logs and monitor application access is stated across all four active security frameworks. CBUAE technology risk guidelines require licensed banks to maintain logs of access to protected financial data and to generate alerts on anomalous access patterns. Those requirements name the same log classes that A01 and A09 describe: access records, authentication events and privilege use. A bank in Abu Dhabi or Dubai that undergoes a web application pentest under those guidelines must demonstrate not only that the application was tested, but that its monitoring stack detected the pentest activity. Evidence of detection is as much part of the submission as the finding list. The CBUAE technology risk guidance does not name OWASP by label, but its log and alert requirements map directly to the four classes this article covers.

DESC security standards require Dubai government entities and their approved suppliers to maintain security event logs and to test monitoring controls as part of annual security assessments. NESA and the UAE Information Assurance Standard set equivalent requirements for entities in federal scope. ADHICS, which governs Abu Dhabi healthcare organisations, adds patient data access logging as a specific obligation. For a Dubai Silicon Oasis entity serving government clients, both DESC and NESA apply simultaneously. A web application pentest that surfaces A09 findings in any of these organisations is not an abstract technical issue: it is a gap in a mandated control, and the regulator can ask for evidence that the gap has been closed, not just identified.

Frequently asked questions