How SQL Injection Works?

SQL injection (SQLi) is a web security vulnerability that happens when an application incorrectly combines user input with an SQL query.

SQL is the language applications use to communicate with databases. If an application treats untrusted input as part of the SQL command itself, a user may be able to change what the database query does.

A Simple Example

Imagine a website has a login form asking for:

Username: alice
Password: ********

The application might build a database query using the information entered by the user.

Conceptually, it could look like:

SELECT * FROM users
WHERE username = 'alice'
AND password = 'password';

The application expects the username and password to be data.

The problem occurs when the application directly places untrusted input into the SQL statement without properly separating the input from the query.

Why Is That Dangerous?

An attacker may try to provide specially crafted input that changes the meaning of the SQL statement.

Instead of the database receiving only the information the application intended, part of the user’s input may be interpreted as SQL syntax.

This can potentially allow an attacker to:

• Bypass authentication
• Access information they should not see
• Modify or delete database information
• In some situations, perform other actions depending on the database and application’s privileges

The exact impact depends on the vulnerability, database, application design, and permissions available to the database account.

The Root Cause

The main problem is usually mixing user-controlled data directly into SQL commands.

For example, this approach is dangerous:

SQL query + user input

The safer approach is to keep the SQL command separate from the user’s data.

This is commonly achieved with parameterized queries or prepared statements.

Conceptually:

SQL command → separate
User input  → separate

The database then treats the user’s input as data rather than allowing it to become part of the SQL command.

How Developers Prevent SQL Injection

The most important defense is to use parameterized queries / prepared statements.

Other security measures include:

• Validate input where appropriate.
• Use database accounts with only the permissions they need.
• Avoid constructing SQL queries by concatenating raw user input.
• Handle database errors without exposing sensitive information.
• Keep application and database software properly maintained.

Input validation can be useful, but it should not be the only defense against SQL injection.

Try It Safely

You can learn SQL injection safely by using an intentionally vulnerable training application in your own lab.

Good practice environments include:

• A local vulnerable web application
• A deliberately vulnerable virtual machine
• A cybersecurity training platform

Never test SQL injection against a website or database unless you have explicit permission to do so.

Your goal at this stage is to understand the vulnerability:

User Input
     ↓
Application
     ↓
Unsafe SQL Construction
     ↓
Database interprets input as SQL

A secure application instead uses:

User Input
     ↓
Application
     ↓
Parameterized Query
     ↓
Database treats input as data

Key Takeaways

• SQL injection occurs when untrusted input can influence an SQL query as code.
• It can potentially lead to unauthorized database access or modification.
• The root problem is unsafe handling of user input.
• Prepared statements and parameterized queries are a primary defense.
• Database permissions should follow the principle of least privilege.
• Practice SQL injection only in systems you own or are explicitly authorized to test.

Next Lesson

Next, learn about Cross-Site Scripting (XSS) to understand how unsafe user input can affect web pages and other users.