How to Test for SQL Injection: Techniques, Payloads, and Tools
SQL injection remains one of the most critical web application vulnerabilities despite being understood for over two decades. It ranks as A03 (Injection) in the OWASP Top 10 and consistently appears in real-world breach reports. The vulnerability exists because the application constructs SQL queries by concatenating user input with SQL syntax, allowing the attacker's input to change the query's meaning. A login form that builds a query like SELECT * FROM users WHERE username = '[input]' is vulnerable if the application does not sanitize the input: submitting ' OR '1'='1 as the username changes the query to return all users.
Testing for SQL injection requires only that you have authorized access to the application and can submit input through its interface. You do not need access to the source code or database, though having either makes testing faster and more precise. Always test only applications you own or have explicit authorization to test. SQL injection testing sends payloads that can modify data, drop tables, or extract sensitive information, so test against development or staging environments, never against production databases with real data.
Identify Input Points
Every parameter that could reach a database query is a potential SQL injection point. The obvious inputs are form fields (login, search, registration, profile updates) and URL parameters (page numbers, sort orders, filter values, resource IDs). Less obvious inputs include HTTP headers (User-Agent, Referer, X-Forwarded-For, Accept-Language), cookies, JSON and XML request bodies, and file upload filenames.
Map the application by browsing it with a proxy like OWASP ZAP or Burp Suite, capturing every request. Review each request for parameters that might be used in database queries. Search endpoints, login forms, user profiles, product listings, and any page that displays data from a database are high-priority targets. API endpoints that accept structured data (JSON, GraphQL) need testing with the same rigor as HTML forms.
Pay attention to parameters that appear to control database operations: IDs (user_id, product_id, order_id), sort parameters (sort=name, order=desc), filter parameters (category=electronics, price_min=100), and pagination (page=2, limit=20). These are more likely to appear directly in SQL queries than free-text fields, which are often sanitized or parameterized because developers expect varied input.
Test for Error-Based Injection
Error-based injection is the easiest type to detect because the application reveals the vulnerability through error messages. Submit a single quote character (') in each input and observe the response. If the application returns a database error message like "You have an error in your SQL syntax" (MySQL), "Unclosed quotation mark" (SQL Server), or "unterminated string literal" (PostgreSQL), the input reaches a SQL query without sanitization.
The single quote works because it closes the string delimiter in the SQL query, causing a syntax error if the rest of the query is not valid. The error message confirms that the input is embedded in SQL and not sanitized.
After confirming that an input is injectable, try payloads that extract information through error messages. MySQL's extractvalue() and updatexml() functions can return query results in error messages. SQL Server's convert() with intentionally wrong types produces errors that include the value being converted. These techniques retrieve database data through the error channel when the application does not display query results directly.
Modern applications often suppress database errors in production, showing generic error pages instead. If submitting a single quote produces a 500 error or a generic error page instead of a database error, the input may still be injectable, but you need blind testing techniques to confirm it.
Test for Boolean-Based Blind Injection
When the application does not show error messages, blind injection techniques infer the vulnerability from differences in the application's behavior. Boolean-based blind injection sends two payloads: one that makes the SQL condition true and one that makes it false, then compares the responses.
For a URL parameter like ?id=5, submit ?id=5 AND 1=1 (always true) and ?id=5 AND 1=2 (always false). If the first returns the normal page and the second returns a different page (empty, different content, or an error), the application is injecting the input into a WHERE clause. The true condition returns results, the false condition does not, proving that the SQL logic is being executed.
For string parameters, the approach is similar but requires closing the string first: ?name=admin' AND '1'='1 (true) and ?name=admin' AND '1'='2 (false). The trailing quote closes the string in the original query, and the AND condition modifies the query's behavior.
Once boolean injection is confirmed, data can be extracted one bit at a time by asking yes/no questions about the database. Is the first character of the database name greater than 'M'? Is the admin password's first character 'a'? Each question is answered by the page's behavior (normal page = true, different page = false), allowing full data extraction with enough requests. This process is tedious manually, which is why SQLMap automates it.
Test for Time-Based Blind Injection
When the application returns identical responses for both true and false conditions (same page content, same status code, same headers), time-based techniques confirm injection by measuring response times. Submit a payload that causes the database to delay its response and check whether the application takes longer to respond.
For MySQL: ?id=5 AND SLEEP(5) causes a 5-second delay if the injection works. For SQL Server: ?id=5; WAITFOR DELAY '0:0:5'. For PostgreSQL: ?id=5; SELECT pg_sleep(5). For Oracle: ?id=5 AND 1=DBMS_PIPE.RECEIVE_MESSAGE('a',5).
Measure the baseline response time first (typically under 1 second), then submit the time-delay payload. If the response takes 5+ seconds, the delay function executed, confirming that the input reaches a SQL query. Use shorter delays (1-2 seconds) to reduce testing time, but ensure the delay is long enough to distinguish from normal network latency.
Time-based injection is the slowest but most reliable blind testing technique because it works even when the application returns completely identical responses for any input. It detects injection purely through timing, which is impossible for the application to mask without also masking legitimate slow queries.
Automate with SQLMap and ZAP
SQLMap is the standard tool for automated SQL injection testing. It detects and exploits SQL injection vulnerabilities across all major database systems (MySQL, PostgreSQL, SQL Server, Oracle, SQLite). Given a URL with a potentially injectable parameter, SQLMap tests all injection techniques (error-based, boolean-blind, time-blind, UNION-based, stacked queries) automatically and reports what it finds.
Basic usage: sqlmap -u "http://target.com/page?id=5" --batch tests the id parameter with default settings. The --forms flag automatically detects and tests form fields. The --crawl flag follows links to discover more testable endpoints. For authenticated testing, pass session cookies with --cookie or use Burp/ZAP proxy logs as input with -r request.txt.
OWASP ZAP includes SQL injection testing in its active scanner. It tests every parameter captured during spidering and manual exploration, using a broad set of SQL injection payloads. ZAP's approach is less thorough than SQLMap for individual parameters but covers all parameters across the entire application in a single scan, making it better for broad assessment. Use ZAP for initial scanning and SQLMap for deeper testing of specific parameters that show potential.
For API testing, submit injection payloads in JSON values, GraphQL variables, and XML elements. SQLMap supports JSON with the --data flag and GraphQL with custom tamper scripts. ZAP tests API parameters when API specifications are imported or when API traffic is captured through the proxy.
Verify and Report
Every positive finding needs verification to confirm it is a real vulnerability, not a false positive. For error-based findings, review the error message to confirm it comes from the database engine and not from application-level validation. For blind findings, repeat the test multiple times and compare results to ensure the behavior difference is consistent and not caused by caching, load balancing, or network variance.
Classify each finding by impact. An injection in a read-only query (SELECT) allows data extraction. An injection in a write query (INSERT, UPDATE, DELETE) allows data modification. An injection that supports stacked queries (multiple statements separated by semicolons) potentially allows arbitrary SQL execution including DROP TABLE, creating admin accounts, or reading files from the database server's filesystem.
Document each finding with the affected URL, parameter name, injection type, a proof-of-concept payload that demonstrates the vulnerability, the database response or behavioral evidence, and the recommended fix. The universal fix for SQL injection is parameterized queries (also called prepared statements), where the SQL structure is defined separately from the data values, making it impossible for input to change the query's meaning.
Report with severity. SQL injection that allows authentication bypass or data extraction is critical. SQL injection in an admin-only endpoint behind strong authentication is high but less urgent. The CVSS scoring system provides a standardized framework for severity classification.
SQL Injection Types Summary
In-band (classic): The attacker sends a payload and receives the result in the same HTTP response. Error-based and UNION-based are in-band techniques. These are the easiest to exploit and detect.
Blind: The application does not return query results or error messages. The attacker infers information from the application's behavior (boolean-based) or response timing (time-based). More difficult to exploit but equally dangerous because data extraction is still possible.
Out-of-band: The attacker triggers the database to send data to an external server they control, using functions like MySQL's LOAD_FILE() combined with DNS resolution or SQL Server's xp_dirtree. Used when neither in-band nor blind techniques work, typically in heavily filtered environments.
Second-order: The injected payload is stored (e.g., in a user profile or comment) and executed when the stored data is later used in a SQL query. Second-order injection is hard to detect with automated tools because the injection point and execution point are on different pages or workflows.
Why Parameterized Queries Fix SQL Injection
The root cause of SQL injection is mixing code (SQL syntax) with data (user input) in the same string. Parameterized queries solve this by separating the two. The SQL query structure is defined with placeholder markers, and the user input values are passed separately. The database engine processes the structure first, then binds the values into the placeholders, ensuring that user input is always treated as data, never as SQL code, regardless of what characters it contains.
Every modern database driver in every programming language supports parameterized queries. In Python with psycopg2: cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,)). In JavaScript with pg: client.query("SELECT * FROM users WHERE id = $1", [userId]). In Java with JDBC: PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE id = ?"); ps.setInt(1, userId);. There is no performance penalty, no complexity increase, and no reason to concatenate user input into SQL strings in any modern application.
SQL injection testing uses error-based, boolean-blind, and time-based techniques to determine whether user input reaches database queries without sanitization. Test every input point that could interact with a database, automate broad scanning with ZAP and targeted testing with SQLMap, and fix every finding with parameterized queries.