How SQL Injection Works: Mechanism, Fine and Fix

Written by Ruben Selby, Founder and Lead Security Consultant, Wolfcore. Last reviewed 7 November 2026.

In one sentence: SQL injection is when a website passes what a visitor types straight into a database question, so the visitor can change the question and read or alter data they should never see.

Part of our Hacking techniques explained library. This guide explains how SQL injection works, step by step.

This page explains the mechanism. For the wider definition, risk rating and where it sits in the OWASP list, see sql-injection.

What SQL injection is

Most websites keep their data in a database. The site asks the database questions in a language called SQL. A product page might ask for “all released products in the Gifts category”.

SQL injection happens when the site builds that question by gluing text together, and part of the text comes from the visitor. PortSwigger’s Web Security Academy describes it as a flaw that allows an attacker to interfere with the queries that an application makes to its database. The database cannot tell which part of the question was written by the developer and which part came from a stranger.

How it works

The site takes an input: a search box, a category in the web address, a login form, even a cookie.
The code joins that input into a SQL query as plain text.
A visitor sends input that closes the text early and adds extra instructions of their own.
The database runs the combined text as one query, including the extra instructions.
The site returns the result, or changes behaviour, based on what the database did.

PortSwigger’s own example is a shop where the category filter hides unreleased products. Changing the input so the rest of the query is ignored shows the hidden products. In a login form, the same idea can remove the password check altogether.

Results are not always visible. In “blind” cases the page shows nothing, but a tester can still work out answers from small differences in the response or from the time it takes. There is also a “second-order” form, where the input is stored safely and used unsafely later.

The attacker is after data (passwords, personal details, card details), or after a way to change data. PortSwigger notes that in some situations it can be escalated to compromise the server behind the database.

Vulnerable pattern and the fix

This is a generic illustration, taken from the pattern PortSwigger shows. The first version builds the query from text. The second keeps the query fixed and passes the input separately.

// Vulnerable: input is joined into the query text
String query = "SELECT * FROM products WHERE category = '" + input + "'";

// Fixed: parameterised query (prepared statement)
PreparedStatement s = connection.prepareStatement(
    "SELECT * FROM products WHERE category = ?");
s.setString(1, input);

Who it affects and how badly

Any organisation with a database-backed website or app. Think of online shops in retail and hospitality, booking systems, customer portals at estate agents and recruitment firms, SaaS start-ups, and fintech and insurance quote forms.

Sole trader to 10 staff: often runs a plugin or template built by someone else. The worst case is stolen customer data and a site taken offline while it is cleaned.
10 to 50 staff: a custom portal is common. The worst case is customer records exposed, an ICO report, and clients asking hard questions.
250 plus, regulated: many sites, some forgotten. The worst case is a regulator penalty plus loss of customers.

PortSwigger says these attacks have been used in many high-profile data breaches over the years, with reputational damage and regulatory fines.

The UK angle: TalkTalk and the ICO

In October 2015 attackers used SQL injection against three old web pages that TalkTalk had inherited through an acquisition. The ICO’s account says the attacker accessed the personal data of 156,959 customers, with bank account details and sort codes taken in 15,656 cases.

The ICO found the database software was outdated. A fix had been available over three-and-a-half years before the cyber attack but had not been applied. There had also been two earlier SQL injection attacks, on 17 July 2015 and 2 to 3 September 2015, with no action taken. The ICO fined TalkTalk £400,000, its biggest fine at the time.

The lesson for a small business is practical. The weakness was well understood, the defences were known, and the failure was not knowing which pages existed and not patching. That fine was under the old Data Protection Act. The same duty to keep personal data secure now sits in UK GDPR.

What we check on a test

This is our method in general terms, not a finding from any client.

Every place the application accepts input: forms, URL parameters, headers, cookies, JSON and XML bodies.
Whether input changes the behaviour of the database, using careful, non-destructive checks agreed in scope.
Pages that return database error text, which tells an attacker too much.
Second-order cases, where stored input is reused later.
Old, forgotten or inherited pages and subdomains, the TalkTalk lesson.
Whether the database account behind the site has more rights than it needs.

How to detect it

Search web server and application logs for requests with unusual quote characters or SQL keywords in parameters, and for bursts of errors from one address.
Watch for database error messages in responses.
Alert on unusually slow or very large database queries.
Run the free web vulnerability scan for a first pass, then have a person confirm anything it flags.
Keep an asset list of every web page and subdomain, so nothing forgotten stays online.

How to fix or prevent it

Use parameterised queries (prepared statements) for every query. PortSwigger says the query string must always be a hard-coded constant containing no variable data from any source.
Where input has to choose a table, column or sort order, which parameters cannot cover, allow only a fixed list of permitted values.
Give the website’s database account only the rights it needs, never an administrator account.
Turn off detailed database errors in production.
Apply updates to the database and the framework promptly. See patch-management.
Remove pages and sites you no longer use.
Test the application by hand before release and after major changes.

FAQ

Is SQL injection still a problem? Yes. PortSwigger still teaches it as a current web vulnerability, and the TalkTalk case shows the cost of leaving it open.

Does a firewall stop it? The sources opened for this page describe the fix as parameterised queries in the code. We make no claim that a firewall alone is enough.

Does it only affect login forms? No. PortSwigger says it can arise in many parts of a query and in input formats such as JSON and XML.

Sources

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. Start with the free web vulnerability scan at https://wolfcore.co.uk/free-web-vulnerability-scan/ or see our web application testing at https://wolfcore.co.uk/services/web-application-penetration-testing/.