- SQL injection explained in everyday language
- What a SQL injection attack can put at risk
- Why SQL injection still turns up
- The main defences against SQL injection
- Least privilege and other safety nets
- Why SQL injection matters to ordinary website visitors
- What website owners can do without writing code
- Where SQL injection fits in version control and teamwork
- Teach what you know about secure coding
- Frequently asked questions
SQL injection is a weakness where a website passes untrusted user input into a database query, so the input can change the commands the database runs. It can expose or alter stored data. OWASP's main defences are parameterised queries, carefully written stored procedures and least-privilege database accounts.
Search boxes, login forms and contact pages all pass whatever you type to a database somewhere behind the scenes. SQL injection is what happens when a website trusts that input too much.
This guide sticks to the defensive side. I've used the OWASP project, which is the standard reference for web application security, to explain the idea, what's at stake and what developers do to prevent it. There are no attack recipes here, just the concepts.
SQL injection explained in everyday language
SQL, short for Structured Query Language, is the language many websites use to talk to their databases. An application might ask the database for 'the customer with this email address' using a SQL query that includes whatever the visitor typed in.
OWASP describes SQL injection as the insertion, or 'injection', of a SQL query via the input data from the client to the application. In short, it occurs when untrusted input changes the database commands an application runs. Imagine a waiter who writes down your order and passes it to the kitchen word for word, including a line you added saying 'and give me the till'. The kitchen can't tell your extra line from the real order, and that's the problem.
What a SQL injection attack can put at risk
OWASP lists several kinds of impact, because databases often hold the most valuable data an organisation owns:
- Confidentiality. Sensitive records can be exposed.
- Authentication. Weak login checks may let an attacker act as another user without knowing their password.
- Authorisation. If permission data lives in the database, it may be changed.
- Integrity. Stored data can be modified or removed.
OWASP rates SQL injection as high-impact in general, with the severity depending on the attacker's skill and the defences in place. That second half is the encouraging part: defences work.
Why SQL injection still turns up
The flaw isn't a bug in the database. It sits in how an application builds its queries, usually by gluing user input directly into the SQL text. It can happen in older code, in quick prototypes and in anything where speed beat care. The same weakness can also be a stepping stone to bigger incidents, including the kind of attack I explain in my guide to ransomware.
The main defences against SQL injection
OWASP's SQL Injection Prevention Cheat Sheet sets out primary defences in order of preference:
- Prepared statements (parameterised queries). The developer writes the SQL first and passes user input in separately as values, so the database never treats input as commands. OWASP says developers should be taught to use these from the start.
- Stored procedures. The SQL is defined in the database and called with parameters. OWASP considers them as effective as prepared statements if written safely.
- Allow-list input validation. Accept only known-good values, such as mapping a user's choice to a fixed sort direction. OWASP calls this the most appropriate defence where a parameter can't be used.
- Escaping user input. OWASP strongly discourages this. It's fragile, depends on the database and can't guarantee protection.
Least privilege and other safety nets
Even with good code, OWASP recommends limiting the damage if something goes wrong. Give each database account only the access it needs, avoid admin-level accounts for applications and use separate accounts for separate apps. OWASP stresses that least privilege limits the damage even when injection occurs.
It also suggests using allow-list validation as a second check on all input, though it warns that validated data still shouldn't be built into queries by joining text together.
Why SQL injection matters to ordinary website visitors
You may never see a database, but you're affected by how well one is protected. Customer lists, order histories and login details are all kinds of data that sit behind a form. When an application handles input carefully, the form does its job and nothing more.
OWASP's impact categories make this concrete. Confidentiality is about who can read the records, authentication is about who can log in as whom, authorisation is about who can do what, and integrity is about whether the data can be trusted. A single weak query can touch all four.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
For a business owner, that translates into a simple question to ask any developer or agency you work with: how do you stop user input from changing database commands? A confident answer will mention parameterised queries or prepared statements, which are OWASP's first recommendation.
What website owners can do without writing code
If you run a site rather than build one, you can still reduce the risk:
- Keep your content management system, plugins and themes updated, because updates fix known weaknesses.
- Ask whoever builds or maintains your site whether queries use prepared statements.
- Use unique, strong passwords and a second login step for admin accounts.
- Keep tested, offline backups so a damaged database can be restored.
Where SQL injection fits in version control and teamwork
Developers catch these problems earlier when code is reviewed and changes are tracked. If you're new to that way of working, what Git is and how it tracks changes is a friendly starting point.
Teach what you know about secure coding
Secure coding is easier when people explain it clearly, and developers learn best from peers.
Security-minded developers may like this list of developer blogs that welcome technical contributors.
Frequently asked questions
Is SQL injection still a threat?
OWASP continues to treat it as a high-impact weakness, so yes. It's preventable, and parameterised queries are its first recommendation.
What's the best way to stop SQL injection?
OWASP's primary defences are prepared statements (parameterised queries) and carefully written stored procedures, with allow-list validation where a parameter can't be used.
Does escaping input stop SQL injection?
OWASP strongly discourages relying on it. It's database-specific and fragile, and it can't guarantee protection.
Does SQL injection only affect big websites?
No. Any application that builds database queries from user input can be affected, whatever its size.
What does least privilege mean for a database?
It means each database account has only the access it needs, so a problem in one part of an application can't reach everything.
