A comment in a SQL query is text the database ignores. Two characters --- and /* - let an attacker delete the rest of the WHERE clause without changing what the parser has already seen.
- L1Fundamentals
- L3Why it's possible
- Use
--and/* */to terminate a query early. - Recognise the MySQL quirk that requires a space after
--. - Combine a tautology with a comment to fully bypass WHERE clauses.
- Explain why comments are useful for both offense and WAF evasion.
- Line comment (--)
- A comment that runs to the end of the line. In MySQL it requires a space or control character after the dashes; in PostgreSQL the space is optional.
- Block comment (/* */)
- A comment that runs from /* to */. Useful when the payload itself needs a closing */ (e.g. a / in a path).
- Truncation
- Cutting off the rest of a query so the parser never sees it. Comments are the most common truncation tool in SQLi.
Two characters that disable the rest of the query
After a SQLi payload breaks out of a string literal, the rest of the application's query is still appended. The classic fix is to delete it with a comment.
-- Original (insecure login)
SELECT * FROM users WHERE username = 'INPUT' AND password = 'INPUT';
-- With a payload: admin'--
SELECT * FROM users WHERE username = 'admin'--' AND password = 'whatever';
-- After parsing, the second half is a comment. Effective query:
SELECT * FROM users WHERE username = 'admin';The MySQL parser requires a space, tab, newline, or other whitespace after -- to recognise it as a comment. Some bypasses against WAFs use --\t (tab) or --\n (newline) instead of a space. PostgreSQL accepts the form without trailing whitespace.
Pick a comment style
Four presets walk through the canonical comment payloads. Notice how the green-highlighted region in the constructed query is the part the database will ignore. The amber banner tells you whether the truncation worked.
SELECT * FROM users WHERE username = '' OR 1=1 -- ' AND password = '…'AND password = '…'clause so it never executes.Comments, WAFs, and a 2020 Cloudflare bypass
WAFs look for the string -- as a sign of an SQLi payload. In 2020, researcher Georgios Skouroupathis showed that splitting the comment with an in-string escape -'-- OR 1=1' -- where the inner ' is preceded by a backslash - defeated several commercial WAFs at the time. WAFs parse the string, the application parses the query: the two parsers disagree, and the WAF misses the payload. The fix is the same as ever - never concatenate.
The real fix is the same as lesson 1
A parameterised query makes comments irrelevant. The user value is bound as a typed parameter; the parser never sees it as a token; -- inside the value is data, not syntax.
// SAFE - the comment inside the value is data
const query = 'SELECT * FROM users WHERE username = $1';
await db.query(query, [username]); // username can be anythingWhat to remember
--and/* */are the two SQL comment forms. MySQL needs whitespace after--.- A payload that ends with
--(or its tab/newline equivalents) deletes the rest of the application's query. - Comments are also a WAF-evasion tool - splitting payloads with comments often defeats regex-based filters.
- Parameterised queries make the lesson moot: comments inside values are just data.
Knowledge check
0/3 answered · 0 correct1.Why does a payload ending in "--" (with a trailing space) often work where "--" alone fails?
2.A payload is admin'/* and the password field is */. The application appends " AND password='INPUT'". What does the parser see?
3.Why do WAF evasion tricks with comments and in-string escapes still work in 2026?