SQL injection is one of the most common and destructive attacks on the web, and it's been that way since the late 1990s. It works by slipping malicious database commands into input fields that a website wasn't designed to question, tricking the server into running code it should never execute. Entire databases, including usernames, passwords, credit card numbers, and private messages, have been stolen this way. Understanding how it works is the first step to understanding why it keeps succeeding.
What SQL actually is
SQL stands for Structured Query Language. It's the programming language that most websites use to talk to their databases. When you log into an account, the website sends a query to its database that looks something like this:
SELECT * FROM users WHERE username = 'alice' AND password = 'abc123';That query asks the database: "Does a user called alice with the password abc123 exist?" If yes, access is granted. The problem is that many web applications build these queries by stitching user input directly into the SQL string without checking it first. That's where attackers step in.
How an attacker exploits it
Imagine a login form. A legitimate user types their username and password, and the site checks the database. An attacker types something different into the username field:
' OR '1'='1The database now receives a query that reads:
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '';Because '1'='1' is always true, the query returns every row in the users table. The attacker bypasses the login entirely. No valid password needed.
More sophisticated attacks go further. An attacker can append a command like DROP TABLE users; and delete the entire user database in one move. Others use a technique called "blind SQL injection," where they ask the database a series of yes-or-no questions to extract information character by character, without the page ever displaying an obvious error.
Real-world consequences
SQL injection isn't theoretical. In 2008, a single SQL injection campaign compromised more than 500,000 websites in a matter of days. In 2012, attackers used SQL injection to breach LinkedIn and expose roughly 6.5 million password hashes. The same technique hit Yahoo in 2012, exposing over 450,000 credentials in plaintext. These weren't obscure targets. They were some of the most visited sites on the internet at the time.
For Australian businesses specifically, a successful SQL injection attack can trigger obligations under the Notifiable Data Breaches scheme administered by the Office of the Australian Information Commissioner. Any breach that is likely to cause serious harm to individuals must be reported. The penalties for failing to notify are real.
What makes websites vulnerable
Three practices make sites easy targets. First, building SQL queries by concatenating strings with raw user input, rather than using prepared statements. Second, running the database connection with administrative privileges, so an injected command has maximum power. Third, displaying raw database error messages to users, which hand attackers a detailed map of the database structure.
Many vulnerable sites are also running outdated software. A content management system that hasn't been updated in two years is far more likely to contain known injection flaws than one patched regularly. This is true for small business websites as much as for large platforms.
How to defend against SQL injection
The single most effective defence is parameterised queries, also called prepared statements. Instead of building a query by stitching in user input, the developer creates the query structure first and passes user data as a separate parameter. The database engine treats that parameter as pure data, never as executable code. A malicious string is just a string.
Beyond that, input validation helps. Checking that a username field contains only letters, numbers, and a handful of symbols, before the query even runs, cuts off a large class of attacks at the door. Stored procedures can add another layer, and using an application firewall gives teams a last line of defence that can flag suspicious query patterns in real time.
Principle of least privilege matters too. The database account your web application uses should only have permission to read and write the tables it needs. Not drop tables. Not create users. Not access other databases on the same server.
If you're thinking about broader digital security, it's worth reading about zero-day exploits, which share the same underlying reality: attackers find gaps that defenders haven't closed yet. SQL injection just happens to be a gap that defenders have known about for nearly 30 years and still sometimes leave open.
Testing your own site
Developers and site owners can test for SQL injection vulnerabilities using tools like sqlmap, an open-source penetration testing tool that automates the detection and exploitation of SQL injection flaws. Running it against a staging environment, with proper authorisation, reveals whether input fields are genuinely sanitised. Penetration testers use it routinely before a site goes live.
A professional security audit goes further, examining code directly and testing edge cases that automated tools miss. For businesses handling sensitive customer data, that kind of review is worth the cost, particularly given how straightforwardly SQL injection can be exploited once a vulnerable endpoint is found.
Why it keeps happening
SQL injection has appeared on the OWASP Top 10 list of critical web application security risks for most of its existence. OWASP (the Open Worldwide Application Security Project) publishes the list based on data from thousands of real-world applications. The persistence of SQL injection on that list isn't because defenders don't know the fix. It's because the volume of code being written, especially by developers who haven't had formal security training, keeps creating new vulnerable entry points faster than old ones are closed.
The fix is well understood. Parameterised queries, least privilege, and input validation together eliminate the vast majority of SQL injection risk. The gap between knowing the fix and applying it consistently across every form field, every API endpoint, and every database call in a large application is where attackers still find room to work. Understanding how it works is part of closing that gap, and that's why SQL injection still deserves a plain-language explanation in 2026.
For a broader view of the threat environment, MediaChannel's guide to what cybersecurity actually covers puts SQL injection into the wider context of digital defence.