SQL Injection Lab
SQLite · Runs entirely in your browser

See how input becomes SQL

Try an input, inspect the query, then switch to parameter binding and run it again.

Loading the local SQLite engine…

Query mode

Task suggestions

SQL query
Application response
Run a query to see the response for this input and mode.
What is happening?

Why the fix works


Teaching reference: schema & seed data

Instructor view. Reveals the data hidden by the exercises, including the blind exercise’s secret.

Scope & teaching notes

These exercises cover authentication bypass, in-band UNION injection, error feedback, and boolean-based blind injection. Input can arrive through forms, cookies, headers, or previously stored data; the underlying issue is building SQL structure from untrusted values.

Prepared statements keep SQL code separate from data. Use allowlists for identifiers such as dynamic column names, which cannot be supplied through value placeholders. Validation and least-privilege database permissions are additional defenses; generic “cleaning” or removing quotes is not a substitute for parameter binding.

This lab uses SQLite syntax. It does not model a secure client-side login: a real application must enforce authentication and authorization on a trusted backend. Time-based injection, second-order injection, and data modification are outside these exercises. Queries run in a worker with a time limit, a 100-row display cap, and a read-only database.

References: sql.js · OWASP SQL Injection Prevention

Reset this exercise? The inputs and query mode will return to their initial values.