SQL injection has appeared on the OWASP Top 10 list of most critical web application security risks for as long as the list has existed. Despite being one of the oldest known web vulnerabilities - it was first documented in 1998 - it remains effective because it exploits a fundamental characteristic of how most web applications work. Understanding it is the first step to protecting against it.
How SQL Injection Works
Most dynamic websites - including every WordPress site - store their data in a database. When a user submits a search, logs in, or fills out a form, the web application takes that input and uses it to construct a database query.
Here is a simplified example. Suppose a login form takes a username and password. The underlying code constructs a SQL query like this:
SELECT * FROM users WHERE username = 'alice' AND password = 'secret123'
Now suppose an attacker enters the following as their username:
' OR '1'='1
If the application naively inserts this into the query, it becomes:
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''
The condition '1'='1' is always true. The query returns all users. The attacker is logged in - possibly as an administrator - without a valid password.
This is the simplest form of SQL injection. More sophisticated attacks can dump entire database tables, modify or delete records, read files from the server's filesystem, and in some configurations, execute operating system commands.
What an Attacker Can Do With It
The practical impact of a successful SQL injection attack depends on the attacker's goal and the database permissions of the web application's database user. Common outcomes include:
Data exfiltration - the attacker retrieves every user record, email address, and password hash stored in your database. Even hashed passwords can be cracked offline if the hashing algorithm is weak.
Authentication bypass - as illustrated above, the attacker logs into admin areas without valid credentials.
Content manipulation - the attacker inserts content into your database, potentially redirecting visitors to malicious sites, injecting spam links that affect your SEO, or defacing your site.
Database destruction - a particularly destructive attacker can delete tables or the entire database.
Why WordPress Is Relatively Protected by Default
WordPress core uses prepared statements for all database queries. A prepared statement separates the SQL code from the data - the database engine receives the query structure and the data values as separate items, so it knows never to treat the data as code. Even if a user enters SQL-looking text into a form field, it is treated as a literal string, not as part of the query.
The WordPress $wpdb->prepare() function is the specific mechanism for this. When WordPress core constructs a database query that includes user input, it goes through prepare(). This is why known SQL injection vulnerabilities in WordPress core are extremely rare.
Why Plugins Are the Main Risk
The problem is that not every WordPress plugin follows the same standards. Plugins vary enormously in code quality, and a plugin written by a developer who is unfamiliar with secure database practices may construct queries by concatenating user input directly into SQL strings - exactly the pattern that makes SQL injection possible.
This is a real and recurring problem. The WordPress security vulnerability database at WPScan documents dozens of SQL injection vulnerabilities in plugins every year. Many of them are in plugins with tens of thousands of active installations.
Protective Measures
Keep everything updated. The most important thing you can do is keep WordPress core, themes, and plugins current. Most SQL injection vulnerabilities in plugins are discovered and patched - but only protect you if you apply the update.
Remove unused plugins. Every installed plugin, even a deactivated one, is potential attack surface. Delete anything you are not actively using.
Use a Web Application Firewall (WAF). A WAF inspects incoming requests and blocks those that match known attack patterns - including SQL injection signatures. Cloudflare's free plan includes basic WAF protection. Sucuri and Wordfence provide more comprehensive WordPress-specific WAF options.
Choose a managed host with server-level protections. dotCanada's hosting environment includes server-level filtering and monitoring that adds a layer of protection against common attacks before they even reach your WordPress installation.
Audit new plugins before installing. Check when a plugin was last updated, how many active installations it has, and whether it has documented security vulnerabilities. A plugin that has not been updated in two years is a risk.
SQL injection is not a mystery you need a computer science degree to guard against. The core protections are consistent updating, limiting your attack surface, and adding a WAF. Handle those three things and your risk drops dramatically.
