SQL Injection From Scratch: How to Practise It Safely in a Lab

SQL injection is a web application vulnerability that lets an attacker interfere with the queries an application sends to its database, by sneaking their own SQL code into a field the application never expected to contain code at all. Done successfully, it can expose an entire database, bypass a login screen without a password, or hand an attacker control of the server underneath. It has been a known vulnerability class since the late 1990s, it still ranks among OWASP's top web application risks today, and it remains one of the first things any penetration tester or bug bounty hunter learns to test for.

This guide walks through what SQL injection actually is, how it works under the hood, the main types you will encounter, and how to practise finding and exploiting it safely, without ever touching a system you do not have permission to test.

What is SQL injection?

Most web applications talk to a database behind the scenes. A login form checks a username and password against a database table. A product page pulls its description from a database record. A search box queries the database for anything matching what you typed. All of that happens through SQL, the language almost every relational database understands.

SQL injection happens when an application takes something a user typed and drops it directly into a SQL query without properly separating the data from the command structure. If an attacker can shape their input carefully enough, the database stops treating it as data and starts treating part of it as an instruction. A username field becomes a place to alter what a login query actually checks. A search box becomes a place to pull data the application was never designed to return.

How does SQL injection actually work?

Picture a simple query behind a blog's article page, structured something like this:

<code>SELECT * FROM articles WHERE id = 1 AND private = 0;</code>

That query fetches the article with an ID of 1, but only if it is marked public. If the application builds this query by directly inserting whatever value comes from the URL, an attacker can change the id parameter to something like <code>1; --</code>. The semicolon tells the database the query has ended, and the double dash comments out everything that follows, including the <code>AND private = 0</code> check. The result: an article that was supposed to be private gets returned anyway, because the condition that would have blocked it never actually ran.

That is the essence of every SQL injection attack. The application trusted user input to behave like data. The attacker made it behave like code instead.

What are the different types of SQL injection?

Not every SQL injection vulnerability behaves the same way, and the type you are dealing with changes how you detect and exploit it.

Classic and union-based injection are the easiest starting point for beginners because the feedback is immediate. Blind injection takes longer to master because you are inferring the answer one true or false question at a time, but the underlying logic is exactly the same.

Where can you practise SQL injection safely and legally?

Every technique above needs to be practised somewhere, and that somewhere cannot be a live website you do not own or have explicit permission to test. Doing this against a real, unauthorised target is illegal, regardless of intent, and it is also unnecessary. Realistic, deliberately vulnerable environments exist specifically so you can build this skill without any legal or ethical grey area.

TryHackMe's SQL Injection room walks through exactly the scenario described earlier in this guide, a vulnerable blog application where you progress from a basic in-band injection through to union-based data extraction, with a mock browser and live SQL query view so you can see precisely how your input reshapes the query in real time. Once the fundamentals feel solid, the Advanced SQL Injection room covers blind and time-based techniques against a target that gives you no direct feedback at all, forcing you to build the inference skills that real-world blind injection demands.

How do you detect and confirm an SQL injection vulnerability?

Detection starts with breaking things on purpose. Add a single quote to any input field that touches a database query, a URL parameter, a login form, a search box, and watch what happens. A clean application handles it gracefully. A vulnerable one throws a database error, behaves unexpectedly, or changes its output in a way that reveals the query underneath.

From there, the process is methodical rather than clever. Confirm the injection point, work out how many columns the original query returns, then build up from a simple proof of concept toward whatever the vulnerability actually allows, whether that is reading data, bypassing authentication, or in the most severe cases, writing to the database or the underlying file system. OWASP classifies injection as one of the most heavily tested vulnerability categories in modern web applications, and SQL injection specifically still accounts for more than 14,000 recorded CVEs, which tells you how often this exact mistake still makes it into production code.

How do you prevent SQL injection?

Every reliable defence against SQL injection comes down to the same principle: never let user input become part of the query structure itself. Parameterised queries, sometimes called prepared statements, are the standard fix. They separate the SQL command from the data being passed into it at the database driver level, so no matter what a user types, it is always treated as a value and never as executable code.

Object-relational mapping libraries provide this protection by default in most modern frameworks, which is part of why classic SQL injection has become less common in new applications, even as it remains widespread in older or poorly maintained code. Input validation and least-privilege database accounts add further layers, but they are supplements to parameterised queries, not substitutes for them.

Frequently asked questions

Is SQL injection still a real threat in 2026? Yes. It remains part of OWASP's injection category, and legacy applications along with poorly reviewed new code continue to introduce it. It has fallen in ranking as awareness has grown, but it has not disappeared.

Do you need to know SQL to learn SQL injection? Basic SQL helps but is not a strict requirement to start. Understanding simple SELECT statements and how a WHERE clause filters results is usually enough to begin, and the rest builds naturally through hands-on practice.

What is the difference between error-based and blind SQL injection? Error-based injection reveals information directly through database error messages. Blind injection reveals nothing directly, so you infer the answer to yes or no questions through changes in the application's behaviour or response time instead.

Can SQL injection be automated with tools? Yes, tools exist to automate detection and exploitation, but relying on them without understanding the underlying mechanics limits how effectively you can adapt when a target behaves differently than expected. Learning it manually first makes any tool far more useful later.

Does SQL injection only affect websites? No. Any system that builds SQL queries from user-controlled input is potentially vulnerable, including desktop applications, APIs, and internal tools, not just public-facing websites.

Start practising SQL injection the safe way

SQL injection is not a niche skill. It is one of the most consistently useful things a beginner in offensive security can learn, precisely because the underlying idea, that mixing data and commands is dangerous, shows up again and again across other vulnerability classes once you understand it here first.

Start the SQL Injection room on TryHackMe