SQL Injection (SQLi) is a critical security vulnerability that occurs when an attacker “injects” malicious SQL code into a web application’s input fields (like a login box or search bar). Because the application doesn’t properly clean this input, the database executes the malicious script as if it were a legitimate command. This allows attackers to bypass security, view private data, or even delete entire databases.

How SQL Injection Works?

Normally, a website takes your input (like a username) and puts it into a predefined database query. Imagine a login form where the backend code looks like this: SELECT * FROM users WHERE username = ‘ + userInput + ‘ AND password = ‘ + passInput + ‘

• Normal Use: You enter admin. The query becomes: SELECT * FROM users WHERE username = ‘admin’ … (This works as intended).
• The Attack: An attacker enters ‘ OR 1=1 — in the username field.
• The Malicious Query: The database now sees: SELECT * FROM users WHERE username = ” OR 1=1 –‘ AND password = …
• The Result: Since 1=1 is always true, and — tells the database to ignore the rest of the line (the password check), the database logs the attacker in without a valid password.

Types of SQL Injection

• In-band (Classic): The attacker uses the same communication channel to launch the attack and see the results (e.g., data appears directly on the screen).
• Inferential (Blind): The attacker doesn’t see data directly. Instead, they ask the database “True/False” questions (e.g., “Does the admin password start with ‘A’?“) and watch for page changes or response delays.
• Out-of-band: The attacker makes the database send the stolen data to a separate server they control (via DNS or HTTP requests).

SQLi vs. XSS: What’s the Difference?

While both involve “injecting” code, they have different targets:

• XSS targets the user by running scripts in their browser.
• SQLi targets the server/database to steal or manipulate stored data.

How to Prevent SQLi?

The most effective way to stop SQLi is to separate the code from the data.

• Prepared Statements (Parameterized Queries): This is the #1 defense. It tells the database: “This part is the command, and this part is just a piece of text (data)“. Even if the text contains SQL commands, the database won’t execute them.

• Input Validation: Only allow expected characters (e.g., a “Zip Code” field should only accept numbers).
• Principle of Least Privilege: Ensure the database account used by the website only has the permissions it needs. For example, a “Search” account shouldn’t have permission to DROP TABLE.