How to Prevent SQL Injection in WordPress

Imagine a hacker entering a password that isn't a password, but a command that deletes your entire database. That is SQL Injection (SQLi).

Despite being one of the oldest web vulnerabilities, it remains the most dangerous. In WordPress, it usually happens when a developer unknowingly passes unsafe user data directly into a database query.

Here is how to code responsibly and prevent SQLi.

---

🛑 The Mistake: Direct Variable Insertion

The most common error is inserting a variable directly into a SQL string.

DO NOT DO THIS:

// ❌ UNSAFE
$id = $_GET['id'];
$results = $wpdb->get_results( "SELECT * FROM $wpdb->posts WHERE ID = $id" );

If the user sets ?id=1 OR 1=1, the query becomes SELECT * FROM wp_posts WHERE ID = 1 OR 1=1. Since 1=1 is always true, the database returns every single post, potentially exposing private data.

---

✅ The Fix: Prepare Your Queries

WordPress provides a built-in method called $wpdb->prepare(). It functions like printf() in C or sprintf() in PHP. It separates the SQL query from the data, ensuring the data is treated as text, not executable code.

DO THIS:

// ✅ SAFE
$id = $_GET['id'];
$results = $wpdb->get_results( 
    $wpdb->prepare( 
        "SELECT * FROM $wpdb->posts WHERE ID = %d", 
        $id 
    ) 
);

Placeholders:

• %d = Integer (numbers)
• %s = String (text)
• %f = Float (decimals)

---

🛑 Mistake: Trusting $_POST or $_GET data

Never assume input is safe. Even if it's from a dropdown menu, a hacker can intercept the request and change the value.

Sanitize First, Validate Second

WordPress has helper functions to clean data before you even use it.

• sanitize_text_field(): Removes HTML tags and checks string safety.
• sanitize_email(): Ensures it's a valid email format.
• absint(): Forces a value to be a non-negative integer.

Example:

$user_email = sanitize_email( $_POST['email'] );
$age = absint( $_POST['age'] );

---

4. The LIKE Statement Trap

This is a specific vulnerability that $wpdb->prepare() alone doesn't fix.

If you are searching for a name:

$name = 'admin'; // User input
$wpdb->prepare( "SELECT * FROM wp_users WHERE user_login LIKE %s", '%' . $name . '%' );

If the user enters %, the query becomes LIKE '%%%', returning ALL users.

The Fix: Use $wpdb->esc_like() before preparing.

$name = $wpdb->esc_like( $user_input ); // Escapes % and _
$query = $wpdb->prepare( "SELECT * FROM wp_users WHERE user_login LIKE %s", '%' . $name . '%' );

---

5. Cast Your Variables (The Ultimate Safety Net)

If you know an input must be a number, force it to be one.

$id = (int) $_GET['id'];
$query = "SELECT * FROM wp_posts WHERE ID = $id";

Because $id is mathematically guaranteed to be an integer now, SQL injection is impossible, even without prepare() (though you should still use prepare for consistency!).

---

6. Don't Hardcode Table Prefixes

You might be using wp_posts now, but what if you migrate the site and the prefix changes to db123_posts for security?

Bad: SELECT * FROM wp_posts

Good: SELECT * FROM {$wpdb->prefix}posts

This makes your code portable and compatible with all WordPress installs.

---

7. When prepare() isn't enough: esc_sql()

Sometimes you have a dynamic order query that prepare() can't handle because you can't put column names in placeholders.

Scenario: Ordering by a user-chosen column.

$orderby = $_GET['sort']; // Could be 'post_title' OR '1=1; DROP TABLE wp_users'
$safe_col = esc_sql( $orderby );
$query = "SELECT * FROM {$wpdb->posts} ORDER BY $safe_col";

Note: For ORDER BY, it's even safer to whitelist allowed columns using in_array().

---

Summary

Security is a mindset, not a feature.

1. Never trust user input.
2. Always use $wpdb->prepare().
3. Sanitize all incoming data.

By following these three rules, you eliminate 99% of SQL injection risks in your custom WordPress development.