What Is SQL Injection? How It Works and How to Protect Your Site

SQL injection is an attack where someone types database commands into your website, through a search box, a login form or the web address itself, and the site runs them. If the code behind that box is careless, a stranger can read, change or delete what’s in your database: customers, orders and passwords.

How SQL injection works

Most websites keep their data in a database: products, orders, customer accounts. The site talks to that database in a language called SQL. When a visitor logs in, the site asks the database something like “find the customer with this email address”.

The trouble starts when the site builds that question by gluing the visitor’s words into it. Then a visitor can type something that isn’t an email address at all, but a piece of SQL that closes the question early and adds one of their own. The database can’t tell which part came from your site and which from the stranger, so it follows both.

Here is the classic textbook example, simplified:

-- what the site sends when someone logs in as anna@example.com
SELECT * FROM customers WHERE email = 'anna@example.com'

-- what it sends when someone types  ' OR '1'='1  into the email box
SELECT * FROM customers WHERE email = '' OR '1'='1'

The second line asks for customers whose email is empty, or where one equals one. One always equals one, so the database hands back every customer.

The same trick works anywhere a site passes what a visitor sends on to its database: search boxes, filters, contact forms, and numbers in the web address such as ?product=42.

What an attacker can do with it

It depends on the site, but the usual list is:

• Read your database: names, addresses, emails, order history and stored passwords.
• Log in as someone else, including an administrator.
• Change or delete data, such as prices, orders or pages.
• Go further. In 2023, attackers used a SQL injection hole in MOVEit Transfer, a file-transfer product, to install a hidden back door called a web shell and steal data, according to the US Cybersecurity and Infrastructure Security Agency (CISA). On WordPress sites, attackers who got in through a hole in the WP Automatic plugin created their own admin accounts and uploaded back doors, WPScan reported.

Real cases

• TalkTalk, 2015. Attackers used SQL injection on three old web pages that TalkTalk had inherited when it bought Tiscali’s UK business in 2009. They reached the personal details of 156,959 customers, and the bank account numbers and sort codes of 15,656 of them. The Information Commissioner’s Office (ICO) fined TalkTalk £400,000. It also found the company’s database software was out of date, with a fix for a known bug available for more than three and a half years before the attack.
• Heartland Payment Systems, 2008. In 2009, US prosecutors charged Albert Gonzalez over the theft of data from more than 130 million credit and debit cards from Heartland, a card payment processor, and other companies. The indictment names the technique: an “SQL injection attack”.
• MOVEit Transfer, 2023. From 27 May 2023, the Cl0p ransomware gang used a SQL injection hole in this file-transfer software (CVE-2023-34362), which organisations run on their own servers, to steal data from them, CISA’s advisory says.
• WordPress plugins, 2024. LayerSlider, a plugin with more than a million active installations, had a SQL injection hole that anyone could use without logging in. It was reported to Wordfence on 25 March 2024 and fixed in version 7.10.1 two days later. In the WP Automatic plugin, a similar hole was published on 13 March 2024, and WPScan had logged 5,576,488 attempts to use it by 24 April.

Why small websites get hit

Nobody has to pick your site by hand. When a hole in a popular plugin is published, bots try it on every site they can find. Patchstack, a company that tracks WordPress security, counted 11,334 new vulnerabilities in WordPress plugins, themes and core in 2025, 91% of them in plugins. For the most heavily targeted ones, the weighted median time from publication to the first attack was five hours.

So on a typical small business site, the places to look are the plugins and themes you installed, and any custom code a developer wrote for you, such as a booking form or a stock search.

How to protect your site

If you run the site:

1. Update plugins and themes, and switch on auto-updates. In WordPress, go to Plugins and click Enable auto-updates next to each plugin, or select them all and use the bulk actions menu. Themes have the same link under Appearance → Themes. Our guide to outdated plugins and software goes through it step by step.
2. Delete plugins you don’t use. A deactivated plugin still leaves its files on your server.
3. Look up the plugins you keep. The WPScan, Wordfence and Patchstack vulnerability databases are free to search. If a plugin you use has a SQL injection hole with no fix, replace it.
4. Ask your developer about any custom code. Does every database query that uses visitor input use parameterised queries, also called prepared statements? On WordPress, is each one built with $wpdb->prepare()? Does the site’s database account have only the permissions it needs, rather than full admin rights?

For your developer, OWASP’s SQL Injection Prevention Cheat Sheet is the reference. OWASP is the non-profit behind the best-known list of web security risks. Its first recommendation is prepared statements with parameterised queries, which keep code and data apart so that nothing a visitor types can change what the query does. It calls relying on escaping user input “strongly discouraged”, and recommends giving the site’s database account the least access it needs. In WordPress, $wpdb->prepare() prepares a query for safe execution in the same way.

What Teyna checks

Teyna’s free check reads only what is already public. It looks for plugins and software on your site that need updating, including ones with a published SQL injection hole, and tells you which update closes each one. Paid plans check again every week and go deeper once you switch that on in your dashboard. Teyna only reads: it never changes, deletes or submits anything on your site, and it doesn’t clean a site that has already been hacked.