SQL Injection is one of the oldest—and still most dangerous—web application vulnerabilities. Despite being over 20 years old, it continues to compromise organizations of every size.
Today, we'll break down:
- What SQL Injection is
- Why it happens
- Real-world examples
- How you can prevent it
🧠 What is SQL Injection?
SQL Injection (SQLi) happens when an attacker manipulates an application’s input to execute arbitrary SQL commands against the backend database.
In simple terms: You let user input end up as part of a database query—without proper filtering or escaping.
🔍 How Does SQL Injection Work?
Most web apps use SQL queries to interact with databases, for example:
SELECT * FROM users WHERE username = '$username' AND password = '$password';
If you naively concatenate user input, an attacker can inject malicious code:
Username: admin
Password: ' OR '1'='1
The resulting query becomes:
SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1';
Since '1'='1' is always true, this query bypasses authentication and logs the attacker in as admin.
Real-World Impact
SQL Injection can lead to:
Authentication bypass
Data theft (e.g., customer data, credit cards)
Data loss or modification
Remote code execution in certain cases
Famous Example:
In 2008, SQL Injection was used to breach Heartland Payment Systems, resulting in 130 million credit card numbers stolen.
Types of SQL Injection
-
Classic (In-Band) SQLi
- The most straightforward type.
- The attacker uses the same communication channel to both launch the attack and receive the results.
- Example: You see database errors or user info directly in the browser response.
-
Blind SQLi
- The application does not return error messages or results.
- Attackers infer database behavior by observing application responses (e.g., success/failure, timing delays).
- Types of Blind SQLi:
- Boolean-based: Inject conditions that return true/false and observe behavior.
-
Time-based: Use SQL functions like
SLEEP()to detect delays and infer results.
-
Out-of-Band SQLi
- The attacker triggers a data transfer to an external server (e.g., via DNS or HTTP).
- Useful when in-band and blind SQLi don't work.
- Requires certain database functions and network permissions.
How to Prevent SQL Injection
✅ Never trust user input.
✅ Use parameterized queries / prepared statements.
✅ Use ORM frameworks carefully (they’re not always secure by default).
✅ Apply least privilege to database accounts (read-only if possible).
✅ Sanitize and validate inputs (e.g., using regex, allowlists).
✅ Hide detailed error messages in production environments.
✅ Keep libraries and software up to date.
Parameterized Query Example (PHP PDO)
$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :username AND password = :password');
$stmt->execute(['username' => $username, 'password' => $password]);
Here, the input values are bound parameters, so they cannot change the query structure.
Testing for SQL Injection
Use Tools like
Always get authorization before testing any systems you don't own.
💬 Got questions, thoughts, or stories about web security? Drop them in the comments below 👇
Top comments (3)
It's fun that I knew about this but still never cared to see an example of SQL injection. I know there are multiple cases, but specifically for the password scenario, I guess it also helps to encrypt/decrypt the value, isn't it? it's not secure either to store raw password values directly in database.
Great post! just one observation, I'm not sure if it's just me, but the main content is repeated twice in this article
Yeah, it's definitely best to hash or encrypt passwords instead of storing them raw or just relying on input filtering.
Thanks for spotting the repetition — I’ve updated it now!
LOL