When user input is concatenated into a database query, an attacker can rewrite that query. See how injection works, then kill it for good with parameterized queries.
Why: SQL injection occurs when user input is glued directly into a query string, so input like " OR 1=1 -- " changes the query’s logic instead of being treated as data — letting an attacker read or alter the database. When: any query built by string concatenation is vulnerable. Where: this is consistently among the most damaging web vulnerabilities because it targets the data itself.
# VULNERABLE — user input concatenated into the query string:
def login(email, password):
query = f"SELECT * FROM users WHERE email = '{email}' AND password = '{password}'"
return db.execute(query)
# Attacker submits email: ' OR '1'='1' --
# The query becomes:
# SELECT * FROM users WHERE email = '' OR '1'='1' --' AND password = '...'
# The "--" comments out the password check -> logs in as the first user.Why: the definitive fix is to never build queries by concatenation — parameterized queries (prepared statements) send the SQL and the data separately, so input is always treated as a value, never as code. When: use parameters for every query with variable input, without exception. Where: an ORM does this for you; if you write raw SQL, always bind parameters.
# SAFE — the driver sends SQL and data separately; input can't change the query:
def login(email, password):
return db.execute(
"SELECT * FROM users WHERE email = %s AND password = %s",
(email, password), # bound parameters, never concatenated
)
# " OR '1'='1' -- " is now just a (wrong) email value. No injection possible.
# Defense in depth: least-privilege DB user, input validation, and an ORM.Why: alongside prevention you want to know when someone is probing you — injection attempts leave tell-tale patterns in logs (SQL syntax in parameters, sudden database errors) that detection rules can flag. When: log and monitor for these patterns, and never expose raw database errors to users (they help attackers). Where: this feeds the detection engineering covered in the SIEM & Threat Detection course.
Signs of SQL injection probing (feed these to your SIEM):
- request parameters containing: ' OR , UNION SELECT , -- , /* , ;
- spikes in HTTP 500s from the database layer
- unusually long or slow queries from one client
- errors like "SQL syntax near..." (never show these to users!)
Prevent with parameterized queries; DETECT with logging + alerting.