SQL Injection Detection: Find Attack Payloads in Logs

Last verified on Nov 8, 2026.

Public web applications are probed by automated scanners as a matter of routine. Most probes fail. A few land. The job of detection is to separate the two: to see the attempt, and then to see whether the application did anything it should not have.

Searching for attack signatures in request logs alone gives you volume and no verdict. The useful version looks at payloads, at how the server responded and at what happened inside the application afterward.

What the evidence looks like

OWASP describes the main families. A SQL injection attack inserts a query through input data from the client, and a successful one can read or modify database data. Path traversal uses dot-dot-slash sequences and their variations, or absolute paths, to reach files outside the web root. Server-side request forgery lets an attacker supply a URL that the server will read or submit data to, which can expose internal services and cloud metadata. AWS documents the instance metadata service at 169.254.169.254, which is why that address is a classic SSRF target.

Examples of what these look like in an access log:

GET /download?file=../../etc/passwd                            404  312
GET /products?id=1%27%20OR%20%271%27%3D%271                    500 1820
GET /search?q=1%20UNION%20SELECT%20username,password%20FROM%20users  200 48211
POST /fetch-preview  body={"url":"http://169.254.169.254/latest/meta-data/"}  200  941

These are examples. The 404 and the 500 are attempts that failed in different ways: the 500 may mean the input reached the database and broke the query, which is worth a closer look. The 200 with an unusually large response to a UNION SELECT is the one to wake someone for.

How to detect it step by step

1. Log the raw request fields. Keep the path, query string, request body size and the first bytes of the body for sensitive routes, the user agent, the client address, the authenticated actor and the response status and size. Redact credentials and personal data before storing bodies.

2. Decode before you match. Attackers encode payloads. URL-decode and normalize case at least twice, then match.

SELECT client_ip, actor, route, status, response_bytes, ts
FROM access_log
WHERE ts > now() - INTERVAL '1 hour'
  AND regexp_like(lower(url_decode(url_decode(query_string))),
      '(\.\./|union\s+select|or\s+1\s*=\s*1|sleep\(|169\.254\.169\.254|file://)')

3. Use a rule set instead of writing one. The OWASP Core Rule Set works by anomaly scoring: it assigns a numeric score to HTTP transactions showing how anomalous they appear and uses that to make blocking decisions. A web application firewall in front of your app logs those decisions. AWS WAF log records carry fields such as action (allow, block, CAPTCHA or challenge), terminatingRuleId and httpRequest. Ship those logs next to your own.

4. Look at the outcome, not the attempt. For each matched request, check what happened next: the status, the response size against the route's norm, database errors in application logs and outbound connections from the server shortly after.

SELECT a.client_ip, a.url, a.status, a.response_bytes
FROM attack_matches a
WHERE a.status = 200 AND a.response_bytes > 3 * (SELECT percentile_cont(0.5) WITHIN GROUP (ORDER BY response_bytes)
                                                  FROM access_log WHERE route = a.route)
   OR a.status >= 500

5. Track attackers by source. Group matches by client address and by actor. A source that works through many payload families in a short time is scanning. Block it and keep the evidence.

Thresholds and pitfalls

Alert at different levels. A single blocked probe is a log line to count. A payload that returned success, or a burst of 500s on the route it targeted, deserves a page.

Pitfalls:

• Constant background noise. Internet scanners hit every site. If every match pages someone, the alert is useless within a week. Alert on outcome and on new payload families, and chart the rest.
• False positives. A blog post about SQL, a support ticket pasted into a form or a code snippet in a comment contains union select. Exclude routes that accept such text, or require more than one signal.
• Evasion. Regular expressions are bypassed with encoding, comments and case tricks. Treat matching as a tripwire, and rely on parameterized queries and input validation as the real defense.
• Missing bodies. Attacks in JSON bodies and headers will not appear in access logs that only record paths.
• Blocked is not safe. A WAF block means one request failed, not that the vulnerability is gone.

What to do when it fires

If the payload succeeded, treat it as an incident: find the route, identify what the response contained and look for the same source across other routes and days. Fix the cause in code, such as parameterized queries for SQL, an allowlist of file names for downloads and an allowlist of hosts for any URL the server fetches.

If it only failed, add the source to a block list for a period, and check that the route handles malformed input quietly. Related guides: bots and scraping, authentication anomalies, risky code for catching the flaw earlier and access anomalies for what follows a successful attempt. Log sources include AWS WAF, Cloudflare and AWS CloudWatch.