SQL Injection Payload Reference

SQL injection (SQLi) happens when user input is concatenated into a SQL query instead of being passed as a bound parameter, letting an attacker change the query's meaning. This reference collects the canonical, widely-documented payloads — the same ones every scanner and WAF already recognizes — organized by technique, so you can reproduce findings during authorized testing and, just as importantly, build and validate detections.

The techniques. Authentication bypass payloads like ' OR '1'='1 turn a login WHERE clause always-true. UNION-based payloads append a second SELECT to exfiltrate data once you know the column count and types. Blind injection is used when the app returns no data or errors: boolean-based payloads compare a true condition against a false one by watching response differences, and time-based payloads (SLEEP(5), WAITFOR DELAY) infer data from response latency. Error-based payloads coax the database into leaking data inside an error message.

How you'll use it. Pick a category to see representative payloads with a note on what each does. Use them to confirm a suspected injection point in a target you are authorized to test, to understand a payload you found in logs, or to write and test WAF rules and IDS signatures against known-bad strings.

The honest caveat. These are reference strings, not a turnkey exploit — real exploitation depends on the database engine, the query context (string vs numeric, inside a LIKE, etc.), quoting, and any filtering. That context-sensitivity is exactly why manual verification matters.

Defensive angle — the actual fix. The definitive defense is parameterized queries / prepared statements, which send the query structure and the data separately so input can never change the query's meaning. Add least-privilege database accounts (so a compromised query cannot read every table), input allowlisting where the value space is known, and an ORM used correctly. A WAF that blocks these strings is a useful speed bump and detection layer, but it is not a substitute for parameterization — attackers routinely URL- or hex-encode and mutate payloads to slip past signatures. Injection rarely travels alone: pair this reference with the XSS payload reference when reviewing an input that reaches both a query and a page.