Find SQL Injection Vulnerabilities with Burp Suite (2026)

Burp Suite can find SQL injection vulnerabilities by actively probing web applications for weaknesses in how they handle user input.

Let’s see Burp Suite in action. Imagine you’re testing an e-commerce site. You navigate to a product page, and the URL looks like this: http://example.com/products?id=123. This id parameter is a prime candidate for SQL injection.

Here’s how you’d use Burp Suite:

1. Configure your browser to use Burp Suite as a proxy. This is usually done in your browser’s network settings, pointing to 127.0.0.1 on port 8080.
2. Navigate to the product page in your browser. Burp Suite will capture the HTTP request.
3. Send the request to Burp’s "Intruder" tool. Right-click the request in the "Proxy" tab and select "Send to Intruder."
4. Identify the parameter to attack. In the "Intruder" tab, go to the "Positions" sub-tab. Burp will usually highlight parameters it finds. Ensure id is selected.
5. Choose an attack type. For SQL injection, "Sniper" is a good starting point. This means Burp will take one payload at a time and insert it into the selected parameter.
6. Load a payload list. Go to the "Payloads" sub-tab. Under "Payload Sets," select "Simple list." Then, under "Payload Options," click "Load" and choose a file containing SQL injection test strings. You can find many such lists online (e.g., SecLists). A basic list might include:
   • ' OR 1=1 --
   • ' OR 'a'='a
   • 123' OR '1'='1
   • 123' UNION SELECT null, username, password FROM users --
7. Start the attack. Click the "Start attack" button. Burp will send a series of requests to the server, each with a different payload injected into the id parameter.
8. Analyze the results. In the "Intruder" results tab, you’ll see a list of requests and their responses. Look for differences in the response length or response content. A successful SQL injection often causes a noticeable change. For example, if id=123 usually returns a page of a certain length, an injection like ' OR 1=1 -- might return all products (because 1=1 is always true), resulting in a much longer response. Or, an error message might appear in the response body, indicating a syntax error in the SQL query.

The core problem Burp Suite helps solve is identifying how an application trusts user-supplied input when constructing database queries. By submitting carefully crafted strings, you can trick the application into executing unintended SQL commands.

Here’s a more detailed look at how it works internally:

• Proxying: Burp acts as an intermediary between your browser and the web server. It intercepts every HTTP request and response.
• Parameter Identification: Burp automatically parses requests to find parameters in URLs, form data, and headers.
• Payload Injection: The Intruder tool systematically replaces the values of chosen parameters with strings from a predefined list.
• Response Analysis: Burp then compares the server’s responses for each injected payload. It looks for patterns that indicate successful injection, such as:
  • Errors: Database errors (e.g., "syntax error," "unclosed quotation mark") often appear in the response body.
  • Content Changes: If a query is altered to fetch more or different data, the page content will change.
  • Timing Differences: In some cases, injections can cause queries to take longer to execute, which Burp can also detect.

Let’s consider the 123' UNION SELECT null, username, password FROM users -- payload. The ' closes the original string, UNION SELECT null, username, password FROM users attempts to append a query that retrieves usernames and passwords from a users table, and -- comments out any remaining part of the original query. If the application is vulnerable and doesn’t properly sanitize input, the database will execute this combined query, potentially revealing sensitive user data.

The most surprising true thing about SQL injection is how often it’s exploitable through seemingly innocuous parameters like sort_order or page_number. Developers often focus on input validation for obvious fields like username or credit_card_number, but forget that any dynamic data used in a database query is a potential entry point.

To effectively use Burp Suite for SQL injection detection, understanding the underlying SQL syntax and common injection techniques is crucial. Simply running automated lists without knowing what to look for in the responses will lead to many false positives and missed vulnerabilities.

The next concept you’ll likely encounter is cross-site scripting (XSS), which also involves injecting malicious input but targets the user’s browser rather than the database.