playbookSecurity Playbooks~1 min readUpdated Apr 23, 2026

Exploit SQL Injection

Goal

Determine whether user-controlled input can alter SQL query logic in a way that changes access, data, or behavior.

Assumptions

  • one or more endpoints send untrusted input to a database layer
  • query construction may not be safely parameterized everywhere
  • secondary features are often weaker than primary flows

Prerequisites

  • endpoints with user-controlled input
  • ability to replay and compare requests
  • safe test environment and authorization to probe

Recon steps

  1. Map all user-controlled inputs: query params, forms, JSON, cookies, headers.
  2. Look for filtering, sorting, search, exports, and admin-only features.
  3. Note error behavior, timing, and content changes.

Exploit / test steps

  1. Send simple syntax probes to detect parser influence.
  2. Test boolean and timing differences where appropriate.
  3. Compare success/failure behavior across endpoints.
  4. Probe less obvious inputs like headers, hidden params, or mobile/API routes.
  5. Confirm whether the issue is read-only, auth bypass, or broader query control.

Validation clues

  • SQL errors or stack traces
  • content differences under boolean conditions
  • measurable timing differences
  • auth or data access behavior changes unexpectedly

Mitigation

  • parameterize queries consistently
  • avoid raw string concatenation
  • constrain DB privileges
  • review query-building helpers and ORMs for unsafe escape hatches
  • monitor suspicious query patterns safely

Logging / detection

  • repetitive syntax-like probes
  • abnormal query timing patterns
  • errors around query parsing or type coercion

References

  • Testing / Lab: PortSwigger SQL injection topic — https://portswigger.net/web-security/sql-injection
  • Foundational: OWASP Top 10 Injection — https://owasp.org/Top10/2021/A03_2021-Injection/
  • Foundational: OWASP WSTG — https://owasp.org/www-project-web-security-testing-guide/latest/