← Back to Guides

💉 SQL Injection Playground

See exactly how SQL injection works against a simulated vulnerable login form — then see the parameterized query fix.

⚠️

Educational simulation only. No real database exists here. All SQL is evaluated in JavaScript to show the logic — nothing is executed on a server. Only use SQL injection knowledge on systems you own or have written permission to test.

Vulnerable login (string concatenation)

Generated SQL query

SELECT * FROM users
WHERE username = 'admin'
  AND password = 'wrong_password'

Try classic payloads:

Safe login (parameterized query)

Parameterized query (never changes)

SELECT * FROM users
WHERE username = $1
  AND password = $2

-- Parameters passed separately:
-- $1 = (user input, treated as data)
-- $2 = (user input, treated as data)

Why this is safe: The query structure is fixed before user input arrives. Input is always treated as a value — never as SQL syntax. Even '; DROP TABLE users-- becomes a literal string that simply won't match.

🔬 What's actually happening

1️⃣

Concatenation vulnerability

The vulnerable app builds SQL like a string: "...WHERE user='" + input + "'". Whatever the user types becomes part of the SQL syntax.

2️⃣

The injection

Typing ' OR '1'='1 closes the string and appends a condition that's always true — so every user matches the query.

3️⃣

Real-world impact

Beyond auth bypass: attackers can dump entire databases, read files, or in some DBs even execute OS commands. OWASP has rated SQLi #1 or #3 in their Top 10 for over a decade.