SQL injection
This page needs a recent browser (with SharedArrayBuffer support). Please update Chrome, Edge, Firefox or Safari to the latest version.
When input becomes a command
- Many apps build a database query by gluing the user's input into a string. That is dangerous.
- If an attacker types SQL as their input, it can become part of the query. This is SQL injection — the most famous web attack.
See the attack
- Imagine a login that checks
... WHERE name = '<whatever you typed>'. - An attacker types
' OR '1'='1as the name. The query becomes:
SELECT * FROM users WHERE name = '' OR '1'='1';
'1'='1'is always true, so the database returns every user. The login is bypassed. Run it and see.
The fix: parameterised queries
- Never glue user input into SQL. Use parameterised queries (also called prepared statements).
- The database treats the input strictly as a value, never as code — so
' OR '1'='1is just a (failed) name to look up. - Also apply least privilege: the web app's database account should only do what it needs.
Your turn
- Below, write a precise, safe query that returns only bob by his
id. That is the spirit of a parameterised lookup.
Covers: A-Level data security; web application security.
A safe lookup uses a precise condition. Change the query to return only bob's row, by adding WHERE id = 2.
Click Run to see the output here.