Inside a Real SQL Injection Attack: How One Unvalidated Input Field Exposed 2.3 Million Records
A single unescaped query parameter in a legacy inventory API became the entry point for an attack that extracted a complete customer database. Here is how the attack unfolded — and how parameterized queries would have prevented it entirely.
The Initial Compromise
During a red team engagement for a mid-sized e-commerce firm, our penetration testers identified a legacy inventory management API endpoint that accepted a numeric product ID parameter. Standard input. Unremarkable. Except it was not sanitized.
A single apostrophe in the query string produced a verbose MySQL error — the first indicator of SQL injection vulnerability. Within minutes, the payload ' OR 1=1 -- confirmed the door was open.
Escalation: From Row Enumeration to Full Database Dump
Using a UNION-based injection chain, the attacker — in this case our own testers — enumerated the schema, identified 23 tables, and targeted the customer_profiles and payment_tokens tables. Using automated tooling comparable to sqlmap, the full extract took 47 minutes across a slow connection.
The data: 2.3 million customer records including names, email addresses, hashed passwords, and partial payment card data. All extracted through a single API endpoint that the development team believed was "internal only."
Why "Internal Only" Is Not a Control
The endpoint was documented as internal but was reachable from any authenticated session — including a low-privilege customer account. This is a classic confused deputy problem: the API trusted the network perimeter rather than validating its own inputs.
The Fix: Parameterized Queries and Defence-in-Depth
The remediation path was straightforward but required discipline across three layers:
- Parameterized queries everywhere — no exceptions for "simple" lookups
- Input validation at the API gateway — numeric IDs should reject non-numeric input before the query layer
- Least-privilege DB accounts — the API user had SELECT, INSERT, UPDATE, DELETE on all tables. It needed SELECT on two.
- WAF rules — deploy SQL injection signature detection on all external-facing endpoints
Practitioner Note
SQL injection remains the #1 web vulnerability year after year not because developers are careless but because it is trivially introduced through convenience — raw string concatenation in query builders, legacy code imported from older projects, or third-party libraries that do not default to parameterization. The discipline is in the review process, not the individual developer.
Cybersecurity expert at HorizonShield, specializing in threat intelligence, incident response, and enterprise security architecture.