SQL Injection Playground
SQL Injection (SQLi) is one of the most prevalent and dangerous web vulnerabilities. This playground lets you experiment with a simulated vulnerable application backed by an in-memory database. Type real payloads, watch how the query is assembled, and observe the consequences - all without touching a real server. The final example demonstrates how parameterized queries neutralize every attack.
The application builds this query by directly concatenating user input:
SELECT * FROM users WHERE username = 'USER' AND password_hash = 'PASS'
Try inserting a tautology to make the WHERE clause always true, or use a
comment to cut off the password check entirely. Classic payloads:
The product search page runs:
SELECT id, name, description, price, category FROM products WHERE name LIKE '%SEARCH%'
A UNION SELECT appends a second query to the results.
As long as it returns the same number of columns, the database will merge the output -
leaking data from any other table, including users.
This endpoint fetches a product by numeric ID - the input is inserted
without quotes because "it's just a number":
SELECT * FROM products WHERE id = ID
By injecting a type-conversion expression, an attacker can force the database to
emit an error message that inadvertently reveals table names, column names,
or even row values from other tables.
Sometimes an application reveals nothing - no results, no errors, only a silent success or failure. The attacker can still extract information by measuring response time. If the condition is true, the database sleeps and the page loads slowly; if false, it responds instantly.
Query:
SELECT COUNT(*) FROM users WHERE username = 'USER'
The fix is simple and reliable: never concatenate user input into SQL. Use parameterized queries (also called prepared statements). The database engine receives the SQL structure separately from the data - so injection is structurally impossible regardless of what the user types.