Originally published in 2016 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.
Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. The vulnerable-site target list this post once contained has been removed. This is the third installment of our SQL injection defense series — parts 1 and 2 covered finding and fixing injection flaws; this part covers what comes after the fix: detection, logging, and ongoing protection.
Why detection still matters after you've fixed the code
Parameterized queries eliminate SQL injection at the source — but no codebase stays fixed by accident. New code ships, dependencies change, legacy endpoints resurface, and regressions happen. A detection layer catches what secure coding misses and tells you when someone is actively probing your applications, which is intelligence worth having.
Log what matters
You can't detect what you don't record. Make sure these are captured and centralized:
- Full request details on database-backed endpoints: URL, parameters, user agent, source IP, and session identity.
- Database error events with the failing query context (logged server-side, never returned to the user): syntax errors, type-conversion failures, and permission denials.
- Query performance telemetry: execution time per query pattern. Time-based blind injection shows up as anomalous delays.
- Authentication and session events tied to the same requests, so you can correlate a probe with an account.
- WAF/edge block events — even blocked attempts are signal; a rising block rate against one endpoint means someone is working on it.
Build alerts that fire on real attacks
Turn the telemetry into detection rules in your SIEM:
- Error-rate anomalies: alert when database errors spike on an endpoint relative to its baseline — classic injection probing.
- Signature matches: flag requests containing SQL keywords, comment sequences, or stacked-query syntax in parameters that should never contain them. Tune to your application's normal input to control false positives.
- Behavioral anomalies: a single client cycling through many parameter values, unusually large result sets served to low-privilege sessions, or response-time patterns consistent with blind extraction.
- Known-bad correlation: match source IPs and request fingerprints against threat intelligence feeds of active scanners.
Ongoing protection: keep the fix fixed
- Test in legal labs continuously: DVWA, bWAPP, and WebGoat remain the right places to train your team and validate scanner coverage — never someone else's production site.
- Scan every release: integrate SAST and DAST into CI/CD so new injection flaws are caught before deployment, not after.
- Re-audit data access: periodically review database account privileges — least privilege drifts over time as features are added.
- Keep the WAF tuned: update rule sets, review what's being blocked, and investigate repeated blocks rather than ignoring them.
- Run tabletop exercises: walk through a "we're being probed" scenario so your team knows who triages the alert, who checks the code, and when to escalate to incident response.
Measure it
Track mean time to detect probing, the number of injection findings per release, and the percentage of database-backed endpoints covered by alerting. If those numbers improve quarter over quarter, your program is working.
Series wrap-up
Part 1 taught you to find injection flaws in your own applications using safe labs. Part 2 covered remediation — parameterized queries, least privilege, and layered controls. This part closes the loop: log the right things, alert on the right patterns, and keep testing so the flaw stays fixed. SQL injection is a solved problem technically; the remaining work is operational discipline.
