SQL injection is a code attack that exploits a website or app which passes user input straight into a database query — the attacker types a fragment of SQL where the app expects a name, an ID or a search term, and the database runs it as an instruction. It is one of the oldest web vulnerabilities and still ranks in the OWASP Top 10 under Injection. This guide covers how SQL injection works, what it actually steals, and the fixes that make it structurally impossible in 2026.
TL;DR
- SQL injection happens when untrusted input is concatenated into a database query instead of passed as a parameter.
- Consequences run from reading customer data to modifying records and, in the worst cases, full database takeover.
- The primary defence is parameterised queries (prepared statements); input validation and least privilege are supporting controls, not replacements.
- SQL injection does not need phishing or staff mistakes — but stolen credentials and social engineering remain the more common paths into small-business systems.
- OWASP publishes a free prevention cheat sheet; the fix is developer practice, not a product you can buy.
What is SQL injection?
Most business apps talk to a database in a language called SQL. When the code that builds those queries pastes user input directly into the query text, the boundary between data the user gave us and instructions for the database disappears. An attacker who can remove that boundary can make the database do anything the app's database user is allowed to do — read, change, delete.
OWASP's SQL injection page documents the pattern: the flaw depends on the fact that SQL makes no real distinction between the control and data planes (OWASP SQL Injection), and the OWASP Top 10:2021 ranks injection among the most critical web application security risks.
How SQL injection works
A simple example shows the whole mechanism. Suppose a login check builds a query like this in application code:
SELECT * FROM users WHERE username = '$user' AND password = '$pass'
If a user submits the value admin' -- as the username, the password check is commented out of the query entirely. That is the entire attack in one line: characters typed as data became instructions. The same idea scales to union queries that dump whole tables, error messages that reveal schema details, and blind variants where the attacker infers database contents from response timing.
What an attacker actually gets
| Goal | Typical technique | Business impact |
|---|---|---|
| Bypass login | Comment out the password clause | Account takeover of any app account |
| Steal data | UNION SELECT to read other tables | Customer PII, pricing, staff records copied |
| Modify or delete | UPDATE or DELETE statements in input | Transaction history corrupted, evidence destroyed |
| Pivot deeper | Read credentials or files reachable by the database account | Path from the website into internal systems |
The pivot row is the one owners underestimate: the database account behind a web app often holds rights the website itself never needed, so a single injection point can expose far more than the public site holds.
How to prevent SQL injection
OWASP's prevention cheat sheet is the industry reference, and its ordering matters (OWASP SQL Injection Prevention Cheat Sheet):
- Parameterised queries (prepared statements). The query structure is fixed in code; user values are bound as data and can never be interpreted as instructions. This is the primary defence, and it is implemented in the code, not bought.
- Stored procedures with safe, parameterised internals, where the platform allows.
- Allow-list input validation — accept known-good formats; never rely on blacklists.
- Escaping inputs only as a last resort — the cheat sheet marks this strongly discouraged as a primary strategy, because escaping is dialect-dependent and easy to get wrong.
Two hardening controls reduce the damage if a flaw slips through: least privilege for the application's database account (it should only touch the tables the app needs) and removing verbose database errors from user-facing pages.
Where SQL injection sits alongside the human layer
SQL injection is a developer problem, and most small-business websites in 2026 sit on platforms where the vendor patches it for them — the modern instance of the flaw is more likely to arrive inside a plugin, a supplier's portal or a SaaS tool than in your own code. That is why the realistic small-business checklist runs:
- Keep platforms and plugins patched; injection flaws in third-party code are found and exploited continuously.
- Ask vendors that hold customer data how they handle input validation and least privilege — a vendor due diligence habit that costs one email per vendor.
- Assume the database is only one of several doors: credential stuffing, phishing and invoice fraud attack the people and passwords around the app. Those are the paths staff training closes — Cyber Aware's security awareness training covers the human layer monthly, and a gap assessment shows which doors are actually open.
FAQ
What is SQL injection in simple terms? Typing database commands into a website field where the app expected ordinary text, so the database executes them as instructions.
What can an attacker do with SQL injection? Whatever the app's database account permits: read customer data, change records, delete history, or reach further into connected systems.
How do you prevent SQL injection? Parameterised queries are the primary defence, backed by allow-list validation, least-privilege database accounts and no verbose errors in user-facing output.
Is SQL injection still a threat in 2026? Yes — the technique is old, but unpatched plugins, custom-built apps and supplier portals keep the attack surface alive, which is why injection still ranks in the OWASP Top 10.
Does a WAF stop SQL injection? It raises the bar and blocks known patterns, but skilled attackers bypass filters; parameterised queries are the only structural fix.
Do small businesses need to worry about SQL injection? Mostly via the platforms and plugins they run and the vendors they trust — patch discipline and vendor questions cover most of the exposure.
One last thing
If your site runs on a managed platform, check today whether every plugin and theme is on its latest version. If you run custom-built software, one question to the developer — are all queries parameterised? — is worth more than any security product you can buy.