Slide 15 of 28
Part 3 · Attack ScenariosSlide 15
Slide 15 · Scenario 2
The error message included the SQL query. The attacker found the injection point.
OWASP Scenario #2 — verbose error messages exposing internal system details.
📄 OWASP API Security Top 10 · 2023 · API8 · Scenario 2
SETUP
An e-commerce API running in production with debug mode enabled.

An e-commerce API has a product search endpoint: GET /api/products/search?q=laptop. The API was deployed to production with the debug flag enabled in its configuration. The web framework is configured to return full exception details in HTTP responses when errors occur.

The exploit: An attacker sends a malformed search query: GET /api/products/search?q=’. The malformed input causes an exception. The API returns HTTP 500 with: the full stack trace (framework, version, file paths), the SQL query that failed (SELECT * FROM products WHERE name LIKE ’%’%’), the database table name, column names, and the exact file and line number of the database call. Armed with the SQL syntax, the attacker now crafts a SQL injection payload. The verbose error turned a simple search error into a confirmed SQL injection vulnerability with a full map of the database structure.
Reconnaissance accelerator

Verbose errors don’t create vulnerabilities — they reveal them. A SQL injection point that would take an attacker hours to confirm through blind probing is confirmed in one request when the error includes the SQL query. A framework CVE that requires version detection through fingerprinting is trivially identified when the version is in the stack trace. Verbose errors compress the time-to-exploit for every other vulnerability in the system.

← Back Scenario 3 →