Introduction

SQL Injection, often written as SQLi, is a common and dangerous security vulnerability that affects applications using SQL databases.

SQL Injection happens when an application accepts user input and directly adds it into a SQL query without proper protection. If the input is treated as part of the SQL command instead of plain data, an attacker may be able to change the meaning of the query.

A secure program should never allow user input to control the structure or logic of a database query. User input should be treated as data, not as executable SQL code.

Easy Real-Life Example

Normal instruction:
Show report for student ID 10.

Unsafe situation:
User input changes the instruction itself.

Secure situation:
User input is treated only as a value,
not as part of the instruction.

SQL Injection is similar. The application should keep the database instruction separate from the user-provided value.

What is SQL?

SQL stands for Structured Query Language.

SQL is used to communicate with relational databases. Applications use SQL to store, read, update, and delete data.

SELECT student_name
FROM students
WHERE student_id = 10;

This query asks the database to return the name of the student whose ID is 10.

What is SQL Injection?

SQL Injection is an injection attack where malicious SQL logic is inserted through user input and becomes part of the database query.

The main problem happens when developers build SQL queries by joining raw user input directly into query strings.

Why SQL Injection is Dangerous

SQL Injection can be dangerous because databases often contain sensitive and important information.

Where SQL Injection Can Happen

SQL Injection can happen anywhere an application sends user-controlled input to a SQL database.

Root Cause of SQL Injection

The root cause of SQL Injection is usually unsafe query construction.

This happens when an application builds SQL by directly combining SQL text and user input.

Unsafe Concept

query = "SELECT data FROM table WHERE field = " + userInput

In this style, the database query and the user input become mixed together. This can allow input to affect query meaning.

Safer Concept

query = "SELECT data FROM table WHERE field = ?"
parameter = userInput

Execute query using parameterized method

In this style, the SQL command and the user input are kept separate.

Unsafe Query vs Safe Query

Example: Login Query Concept

Consider a login system. A user enters an email and password. The application checks the database to verify whether the account exists.

Unsafe Login Query Concept

query = "SELECT user FROM users WHERE email = '" + email + "' AND password = '" + password + "'"

This is unsafe because the user-provided email and password are directly inserted into the query text.

Safer Login Query Concept

query = "SELECT user FROM users WHERE email = ? AND password_hash = ?"

parameters:
emailValue
passwordHashValue

Execute query using parameterized method

This is safer because the query structure is fixed and user values are passed separately.

Primary Defense: Parameterized Queries

Parameterized queries, also called prepared statements, are one of the most important defenses against SQL Injection.

In a parameterized query, the SQL structure is defined first, and user input values are passed separately as parameters.

SQL structure:
SELECT product_name FROM products WHERE product_id = ?

Parameter:
productId

Result:
The database treats productId as a value, not as SQL code.

Language-Neutral Parameterized Query Example

FUNCTION getStudentById(studentId)
    query = "SELECT student_name FROM students WHERE student_id = ?"

    result = EXECUTE_PARAMETERIZED_QUERY(query, studentId)

    RETURN result
END FUNCTION

This approach separates the command from the data.

Input Validation is Still Important

Parameterized queries are the primary defense, but input validation is still important.

Input validation checks whether user input is expected before the application uses it.

Example:
studentId should be a positive number.

Validation:
- studentId must be present.
- studentId must be numeric.
- studentId must be greater than zero.

Input validation improves data quality and reduces unexpected application behavior.

Allowlist Validation

Allowlist validation means accepting only known safe and expected values.

This is especially useful when selecting fields such as sort order, report type, or category.

allowedSortFields = ["name", "date", "marks"]

IF selectedSortField is in allowedSortFields THEN
    ACCEPT selectedSortField
ELSE
    REJECT selectedSortField
END IF

Allowlist validation is useful when a value cannot be passed as a normal query parameter, such as a column name or sort field.

Least Privilege for Database Access

Least privilege means giving the application database account only the permissions it actually needs.

Even if a vulnerability exists, least privilege can reduce the damage.

Safe Error Handling

SQL errors should not reveal database structure, table names, column names, query details, or server information to users.

Unsafe Error Message

SQL error near students_table at column student_password_hash

Safer Error Message

Something went wrong while processing your request.
Please try again later.

Detailed error information should be logged securely for developers, while users should see safe and simple messages.

Monitoring SQL Activity

Monitoring can help detect suspicious database activity.

Logs should be useful for security analysis but should not expose passwords, tokens, or sensitive database values.

Defense in Depth Against SQL Injection

SQL Injection prevention should not depend on only one control.

Defense in depth:
1. Use parameterized queries.
2. Validate input.
3. Use allowlists for fixed options.
4. Apply least privilege.
5. Hide detailed database errors.
6. Monitor suspicious activity.
7. Review database code during code review.
8. Keep frameworks and database libraries updated.

Parameterized queries are the main defense, while the other controls reduce risk and impact.

Student-Friendly Example: Student Search

Suppose a school portal allows searching a student by ID.

Bad Code Concept

INPUT studentId

query = "SELECT * FROM students WHERE student_id = " + studentId

result = RUN query

DISPLAY result

This is unsafe because the input is directly joined into the SQL query.

Improved Secure Version

INPUT studentId

IF studentId is not a number OR studentId <= 0 THEN
    DISPLAY "Invalid student ID"
    STOP
END IF

query = "SELECT * FROM students WHERE student_id = ?"

result = EXECUTE_PARAMETERIZED_QUERY(query, studentId)

DISPLAY result

The improved version validates the input and uses a parameterized query.

Real-World Example: Product Search

In an e-commerce application, users may search products by name, category, or price range.

Common Beginner Mistakes

Best Practices to Prevent SQL Injection

Prerequisites Before Learning SQL Injection

Students should understand the following topics before learning SQL Injection deeply:

Trace Table Example: Safe Student Lookup

FUNCTION getStudent(studentId)
    IF studentId is not a number OR studentId <= 0 THEN
        RETURN "Invalid student ID"
    END IF

    query = "SELECT student_name FROM students WHERE student_id = ?"

    result = EXECUTE_PARAMETERIZED_QUERY(query, studentId)

    RETURN result
END FUNCTION

Practice Activity: Fix Unsafe SQL Query Concept

Improve the following pseudocode by applying SQL Injection prevention practices.

INPUT productId

query = "SELECT * FROM products WHERE product_id = " + productId

result = RUN query

DISPLAY result

Sample Improved Version

INPUT productId

IF productId is not a number OR productId <= 0 THEN
    DISPLAY "Invalid product ID"
    STOP
END IF

query = "SELECT * FROM products WHERE product_id = ?"

result = EXECUTE_PARAMETERIZED_QUERY(query, productId)

DISPLAY result

The improved version validates input and uses a parameterized query instead of directly joining input into SQL text.

Practice Test Cases

SQL Injection Prevention Checklist

Mini Quiz

Interview Questions on SQL Injection Concept

Quick Summary