SQL Injection Demo

Interactive educational simulation showing how SQL injection works, why it is dangerous, and how parameterized queries prevent it.

Educational Disclaimer: This tool is a 100% simulated JavaScript demo. There is no real database, no real server, and no real vulnerability. All "SQL queries" shown are constructed strings for visualization only. This tool is for learning and security awareness only. Never attempt SQL injection on systems you do not own or have explicit written permission to test.
0Completed
5Total
0Successful Attacks

Vulnerable Login — localhost:8080
-- SQL query will appear here when you submit --
Try these payloads:

Defense: Parameterized Queries

Level 1 — Try logging in with the username and password fields.

What Is SQL Injection?

SQL injection (SQLi) is a web security vulnerability that allows attackers to interfere with the queries an application makes to its database. It is consistently ranked as the number one web application security risk in the OWASP Top 10 and has been responsible for some of the most high-profile data breaches in history, including the 2011 Sony PlayStation Network breach that exposed 77 million accounts and the 2008 Heartland Payment Systems breach involving 130 million credit card numbers.

How SQL Injection Works

Vulnerable applications build SQL queries by concatenating user-supplied input directly into the query string. Consider a login form that checks credentials with:

SELECT * FROM users WHERE username = 'INPUT_USERNAME' AND password = 'INPUT_PASSWORD'

If a user enters ' OR '1'='1 as the username, the resulting query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''

Due to operator precedence, this is evaluated as username = '' OR ('1'='1' AND password = ''). Since '1'='1' is always true when the password is empty, this can return rows. More effective is ' OR '1'='1' -- which comments out the password check entirely.

Types of SQL Injection

Classic (In-Band) SQL Injection

The most common type, where results are returned directly in the HTTP response. Includes union-based injection (using UNION SELECT to retrieve data from other tables) and error-based injection (using database error messages to extract information).

Blind SQL Injection

When the application does not return query results or error messages, attackers use boolean-based or time-based blind injection. Boolean-based: ask yes/no questions by observing different application responses. Time-based: use SLEEP() or WAITFOR DELAY to infer information by measuring response time.

Out-of-Band SQL Injection

Uses database features to send data to an external server controlled by the attacker (e.g., DNS lookups via LOAD_FILE() in MySQL or xp_dirtree in SQL Server). Rare but extremely dangerous.

Defenses Against SQL Injection

Parameterized Queries (Prepared Statements)

The gold-standard defense. User input is passed as a parameter, never concatenated into the SQL string. The database driver handles all escaping. Works in every major programming language and database.

Stored Procedures

Pre-compiled SQL stored in the database. When called with parameters, the input is treated as data. However, stored procedures that build dynamic SQL internally can still be vulnerable.

Input Validation and Allowlisting

Validate that inputs conform to expected formats (integers, emails, etc.). Use allowlists (only permit known-good characters) rather than denylists (trying to block known-bad characters, which attackers can always bypass).

Principle of Least Privilege

Database accounts used by the application should have only the permissions they need. A web app that only reads data should use a read-only database account. This limits the damage of a successful injection.

Web Application Firewalls (WAFs)

A WAF can detect and block common SQL injection patterns as a defense-in-depth measure. However, WAFs should never be the primary defense — they can be bypassed by sufficiently obfuscated payloads and do not fix the underlying vulnerability.

Frequently Asked Questions

SQL injection is a code injection technique where an attacker inserts malicious SQL code into an input field that is then executed by the database. It is one of the most common and dangerous web vulnerabilities, consistently ranked #1 in the OWASP Top 10.
When a vulnerable login query is built by string concatenation, entering ' OR '1'='1 in the username field changes the SQL from SELECT * FROM users WHERE username='INPUT' AND password='...' to SELECT * FROM users WHERE username='' OR '1'='1' AND password='...'. Since '1'='1' is always true, the WHERE clause returns rows for every user.
Parameterized queries separate SQL code from user data. Instead of building the query by string concatenation, you write the query with placeholders (? or :name) and provide the user input as separate parameters. The database driver handles escaping and ensures input is always treated as data, never as SQL code.
Yes. This demo is 100% simulated in JavaScript in your browser. There is no real database, no real server, and no real vulnerability. The 'SQL queries' shown are constructed strings for educational visualization only. They are never executed against any real database engine.
First-order SQL injection occurs when malicious input is immediately used in a SQL query. Second-order (or stored) SQL injection occurs when malicious input is safely stored in the database, but later retrieved and used unsafely in another SQL query. Second-order injection is harder to detect because the injection and execution are separated in time and code.