SQL injection (SQLi) is a web attack where a hacker sneaks malicious database commands into a website’s input fields — like a login box or search bar — tricking the site into running them. A successful attack can expose, alter, or delete an entire database: usernames, passwords, payment details, everything. It’s one of the oldest and most damaging web vulnerabilities, and it still ranks on the OWASP Top 10 . Here’s how it works and how to stop it.
Reviewed and kept current by the Coppers.io editorial team — see how we research .
How SQL injection works
Most websites store data in an SQL database and build queries using input you provide. If a site naively glues your input straight into its query, an attacker can supply input that changes the query’s meaning.
A classic example: a login form builds SELECT * FROM users WHERE name = '[input]'. If an attacker enters ' OR '1'='1 instead of a username, the condition becomes always-true — and the query may return every user or log them in without a password. More advanced payloads can dump tables, bypass authentication, or run administrative commands.
What attackers can do with it
- Steal data — read usernames, password hashes, emails, and payment info.
- Bypass logins — authenticate as another user or an admin.
- Modify or delete data — tamper with or wipe records.
- Escalate — in some cases, take over the underlying server.
Because databases sit at the heart of most apps, SQLi is high-impact — which is why it features in so many major breaches.
Types of SQL injection
- In-band — the attacker sees results directly, via error messages or returned data.
- Blind — no visible output; the attacker infers data from the app’s behaviour or response timing.
- Out-of-band — data is exfiltrated through a separate channel.
How to prevent SQL injection
The good news: SQLi is well understood and very preventable. For developers:
- Use parameterised queries / prepared statements — the single most important defence. They separate code from data, so input can never be executed as a command.
- Use an ORM that parameterises queries by default.
- Validate and sanitise input — enforce expected types and formats (defence in depth, not a replacement for parameterisation).
- Apply least privilege — the app’s database account should have only the permissions it needs.
- Hide detailed error messages that reveal database structure.
- Add a web application firewall to filter known injection patterns as an extra layer.
If you run a site on a platform, keep your CMS and plugins patched — see WordPress security and general website security .
SQL injection vs XSS
Both are injection attacks from the OWASP Top 10, but they target different things: SQLi attacks the database behind the app, while cross-site scripting (XSS) injects scripts that run in other users’ browsers. Defending against both comes down to the same rule: never trust user input.
The bottom line
SQL injection tricks a website into running attacker-supplied database commands, potentially exposing or destroying everything it stores. It’s been a top web threat for decades, yet it’s highly preventable: parameterised queries are the core fix, backed by input validation, least-privilege database accounts, and a WAF. If you run a site, keep your platform patched; if you build one, never concatenate user input into queries.
FAQs
- It's a web attack where someone types malicious database commands into a website's input fields. If the site isn't built securely, it runs those commands — letting the attacker read, change, or delete the data behind the site.
- A lot of damage: stealing usernames, password hashes, and payment data; bypassing logins to impersonate users or admins; modifying or deleting records; and sometimes taking control of the underlying server. Because databases hold an app's core data, the impact is often severe.
- The main fix is parameterised queries (prepared statements), which keep user input from being executed as commands. Back that with input validation, least-privilege database accounts, hidden error details, an ORM, and a web application firewall. Site owners should also keep their CMS and plugins updated.
- Yes. Despite being decades old and well understood, SQL injection still appears on the OWASP Top 10 and in real breaches, because insecure code keeps getting written. The defences are well known, which makes it one of the more avoidable serious vulnerabilities.
- SQL injection targets the database behind a website, running malicious queries. Cross-site scripting (XSS) targets other users' browsers, injecting scripts that run when they visit the page. Both are injection flaws, but they attack different parts of the system.