How I Found a (Sanitized) SQLi in a Search API

Published Nov 7, 2025 • 6 min read

Summary

During an authorized assessment of an e-commerce search endpoint, I identified concatenation of user input into an SQL query. Using safe, non-destructive boolean checks and timing tests I confirmed the vulnerability and recommended prepared statements and least-privilege DB roles as the fix.

1) Discovery

The application exposed a search API at /api/search?query=.... Responses included structured hints (row counts, error fragments) useful for further probing.

2) Safe Testing (sanitized)

Always test safely. I used boolean checks that don't modify data. Example (sanitized):

GET /api/search?query=test' AND (SELECT 1 FROM (SELECT COUNT(*),CONCAT(0x7e,(SELECT 'x'),0x7e,FLOOR(RAND(0)*2))a FROM information_schema.tables GROUP BY a)b)-- 

Note: The above is an illustrative, sanitized payload—only run during authorized testing with permission.

3) PoC & Impact

I verified boolean-based injection and could read limited schema metadata. Impact: potential data exposure depending on DB privileges. Patch mitigations were prioritized as high.

4) Remediation

• Use prepared statements / parameterized queries (no string concatenation).
• Use least-privilege DB accounts for app connections.
• Implement input validation + WAF rules for suspicious payloads.

5) Responsible Disclosure

I reported the finding through the vendor's security contact with PoC, remediation steps, and retested after patching. The vendor confirmed the patch within their SLA.