← Back to all labs
OWASP A05 · LAB ENVIRONMENT

Injection

Injection flaws occur when untrusted input is passed to an interpreter as part of a command or query, letting attackers alter the intended logic — from stealing entire database tables to bypassing authentication. Try the interactive playground below to see a classic SQL injection login bypass, and how parameterized queries stop it cold.

OWASP TOP 10 · 2025 · A05 — INJECTION

Injection: When Untrusted Input Rewrites Your Logic

Injection happens when untrusted input is concatenated directly into a command or query interpreter — SQL, NoSQL, an OS shell, LDAP — so the interpreter can no longer tell data from code. A carefully crafted string like ‘ OR ‘1’=’1′ — doesn’t just fill a field, it changes the meaning of the query itself. Below, try logging into a simulated bank admin panel in both a vulnerable and a secure implementation to see exactly how that happens.

Parameterized Queries
Vulnerable Secure

Simulated backend

Enter credentials and click “Log in” to see how the backend builds and runs the query.

Vulnerable vs. secure code

✗ String concatenation
query = (
  "SELECT * FROM users WHERE "
  "username='" + user + "' "
  "AND password='" + pass + "'"
)
cursor.execute(query)
✓ Parameterized query
query = (
  "SELECT * FROM users WHERE "
  "username=%s AND password=%s"
)
cursor.execute(query, (user, pass))
Why this matters: Injection has topped critical-vulnerability lists for years because it’s easy to introduce and devastating in impact — a single unsanitized query can let an attacker bypass authentication, read every row in a database, or modify and delete data outright, resulting in full compromise of the application’s data layer.

How to detect & fix