PaXa Labs / 11 · Application Security

SQL Security Playground

See how unsafe query construction changes application logic and how parameters prevent it.
QUERY SAFETYVULNERABLE
0 / 4 CHALLENGES EXPLORED
APPLICATION

Fictional Login

SIMULATION PRESETS
GENERATED SQL

Concatenated statement

SELECT id, username, role
FROM users
WHERE username = 'alice'
  AND password = 'demo123';
APPLICATION SQL + USER INPUT INSERTED INTO SQL TEXT
IN-MEMORY DATABASE

users

IDUSERNAMEROLE
1aliceuser
2bobuser
3adminadmin
4charlieuser
Fictional data · Password fields intentionally omitted
CONDITION EVALUATOR

Query logic visualizer

username = 'alice'TRUE
ANDOPERATOR
password matches same accountTRUE
FINAL RESULTNOT RUN
EXECUTION TRACE

Unsafe concatenation path

  1. 1Application receives user input.
  2. 2Input is concatenated directly into the SQL text.
  3. 3The simulator recognizes operators introduced by the input.
  4. 4The original WHERE condition changes.
  5. 5Unintended fictional rows may match.
  6. 6The demo application treats the result as authenticated.
SECURITY PRINCIPLE

Keep code and data separate

Direct concatenation makes it possible for untrusted characters to become part of the SQL structure.

HOW TO PREVENT ITUse parameterized queries or prepared statements. Do not build SQL statements by concatenating untrusted values.