Detecting SQL Injection and Data Exfiltration in nginx Logs

Why this matters

SQL injection is decades old, but it’s still one of the most common ways an attacker turns a public-facing form or API parameter into a path to your database. The dangerous part isn’t the initial probe — it’s almost always followed within minutes by a burst of large, successful (200) responses as the attacker confirms the injection works and starts pulling data. nginx access logs capture every step of that sequence in the request field, even though nginx itself has no idea anything malicious happened.

Indicators to look for in nginx logs

• Classic SQLi syntax in the query string or path: UNION SELECT, ' OR '1'='1, SLEEP(, encoded variants (%27, %20OR%20)
• A spike in response size on endpoints that normally return small payloads
• Sequential probing across multiple parameters on the same endpoint, then a narrowing-in on the one that returns a different response time or size
• Successful (200) responses immediately following a string of 400/500 errors on the same path from the same IP
• Requests to endpoints with database-adjacent naming (/export, /report, /api/v1/users?id=)

How LogTriage detects this

The path sensitivity classifier scores endpoints by how sensitive their function is, and combines that with status code and response patterns from the nginx parser. Because this attack chain often touches multiple distinct risk signals at once — a sensitive path, an anomalous user-agent, and (when the attacker pivots to downloading the result) a flagged destination — LogTriage’s compound-signal rule boosts the score by 1.25× once three or more independent high-severity indicators show up on the same event, on top of whatever the individual signals already contributed.

Detection / evidence checklist

• Identify all endpoints that received SQLi-pattern query strings or path segments
• Pull the full request/response sequence for the source IP across the incident window, not just the matching line
• Check for unusually large response bodies immediately after the injection succeeded
• Determine whether the targeted table/endpoint contains regulated data (PII, payment data, health data) — this changes your compliance notification obligations
• Patch the underlying query — parameterization, not a WAF rule, is the actual fix