Burp Suite for QA Engineers — Web Security Testing

What is Burp Suite?

Burp Suite is the industry-standard web security testing platform, developed by PortSwigger. At its core, it is an intercepting HTTP/HTTPS proxy — it sits between your browser and the target application, capturing and allowing you to inspect, modify, and replay every request and response. For QA engineers, this visibility is transformative: it exposes exactly what data is being sent to and received from the server, with no guessing required.

Burp Suite comes in two editions:

• Community Edition (free): Proxy, HTTP History, Repeater, Intruder (throttled), Decoder, Comparer, Passive Scanner. Sufficient for most manual security testing work by QA engineers.
• Professional Edition ($449/user/year): Everything in Community plus the active vulnerability scanner, unlimited Intruder speed, Collaborator (for out-of-band testing), and advanced scanning configurations. Preferred by dedicated security engineers.

This guide focuses on what QA engineers can do with the free Community Edition, which is more than enough to find the most common web security vulnerabilities in a test environment.

Proxy Architecture Diagram

Initial Setup

Getting Burp Suite working with your browser takes about ten minutes but is critical to get right, especially for HTTPS traffic.

Step 1 — Configure browser proxy

Install the FoxyProxy extension for Chrome or Firefox. Create a new proxy entry pointing to 127.0.0.1:8080 and activate it when you want to route traffic through Burp. Never leave FoxyProxy active when not testing — it will break normal browsing if Burp is not running.

Step 2 — Install Burp CA Certificate for HTTPS

Without the CA certificate, Burp cannot decrypt HTTPS traffic and your browser will show security warnings.

1. With FoxyProxy active and Burp running, navigate your browser to http://burpsuite
2. Click "CA Certificate" to download cacert.der
3. In Chrome: Settings → Privacy → Security → Manage Certificates → Import cacert.der into "Trusted Root Certification Authorities"
4. In Firefox: Settings → Privacy → View Certificates → Import cacert.der → check "Trust this CA to identify websites"

Step 3 — Scope your target

In Burp, go to Target → Scope → Add → enter your target domain (e.g., https://staging.example.com). Then in Proxy settings, enable "Intercept only in-scope requests." This prevents your HTTP History from filling up with irrelevant third-party traffic from ads, analytics, and CDNs.

Proxy / Intercept Tab

The Intercept tab is Burp's most fundamental feature. When Intercept is On, every request from your browser pauses in Burp before it reaches the server, allowing you to inspect, edit, or drop it.

• Forward: Send the request to the server as-is (or after editing).
• Drop: Discard the request — useful for blocking specific resources or testing how the application handles missing requests.
• Intercept is on/off toggle: Turn off intercept when you want to browse normally but still have traffic captured in HTTP History.
• Action menu: Send to Repeater, Intruder, or other Burp tools from within the Intercept tab.

A key workflow: intercept a login request, observe the exact parameters sent (username, password, CSRF token), then forward it. This tells you exactly what the server expects, which is the starting point for all subsequent security testing.

HTTP History

HTTP History (in Proxy → HTTP history) is a complete log of all requests and responses Burp has captured. Even with Intercept off, traffic is still captured here as you browse the application normally.

Key features for QA:

• Filter by host: Click the Filter bar and set "Show only in-scope items" to focus on your target.
• Search in responses: Use Ctrl+F within the response panel to search for keywords (e.g., "admin", "debug", "token", "password") across responses.
• Sort by status code: Click the Status column to sort — look for unexpected 500 errors or interesting 403 responses that might indicate security controls are in place.
• Send to Repeater: Right-click any interesting request and send it to Repeater for further manual testing without re-browsing.

Repeater

Repeater is where most of the manual security testing happens. It lets you take a captured HTTP request, modify any part of it, send it, and view the response — all without needing a browser. You can iterate rapidly through dozens of test payloads.

Auth bypass attempt in Repeater

-- Original request (sent to Repeater from HTTP History) --
GET /api/admin/users HTTP/1.1
Host: staging.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...USER_TOKEN...

-- Test 1: Remove auth header entirely --
GET /api/admin/users HTTP/1.1
Host: staging.example.com
[No Authorization header]
-- Expected: 401 Unauthorized --

-- Test 2: Use standard user token on admin endpoint --
GET /api/admin/users HTTP/1.1
Host: staging.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...STANDARD_USER_TOKEN...
-- Expected: 403 Forbidden --

-- Test 3: Manipulate user ID in path --
GET /api/users/100/profile HTTP/1.1
Host: staging.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...USER_200_TOKEN...
-- Expected: 403 Forbidden (user 200 accessing user 100's profile) --

The beauty of Repeater is speed — you can run all three of these tests in under two minutes once you have the initial request captured. In a browser, this would require logging in as different users, navigating to the page, and using browser developer tools to see the raw request.

Intruder

Intruder automates sending a request with varying payloads in specified positions. It is Burp's fuzzing tool, used for brute force, parameter enumeration, and input validation testing.

Setting up Intruder

1. Right-click any request in HTTP History or Repeater and select "Send to Intruder."
2. In the Positions tab, Burp automatically highlights potential injection points with §markers§. Clear them all, then manually mark only the positions you want to fuzz.
3. In the Payloads tab, select your payload type (Simple List, Numbers, Brute Force) and add or paste your payload list.
4. Click "Start Attack."

Attack types:

• Sniper: One position, one payload at a time. Good for testing a single parameter.
• Cluster Bomb: Multiple positions, all combinations of multiple payload lists. Good for testing username + password combinations.
• Battering Ram: Same payload inserted into all positions simultaneously. Good for username enumeration.
• Pitchfork: Multiple positions, payload lists iterated in parallel (list 1 item 1 + list 2 item 1, then item 2 + item 2, etc.).

Note for Community Edition: Intruder is throttled in Community Edition — requests are sent one per second. This is sufficient for small payload lists but makes large brute-force attempts impractical. Use ffuf or wfuzz from the command line for high-speed fuzzing instead.

Passive Scanner (Community Edition)

The passive scanner in Community Edition analyses traffic that passes through the proxy without sending any additional requests. It looks for common security issues in what the application is already doing.

Common passive scan findings:

• Missing security headers: X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security absent from responses.
• Insecure cookies: Session cookies without the Secure or HttpOnly flag.
• Information disclosure: Server or X-Powered-By headers revealing software versions.
• Mixed content: HTTPS pages loading HTTP resources.
• Verbose error messages: Stack traces or server version info in error responses.

To review passive scan findings: go to Dashboard → Issues (or Target → Site Map → Issues). All issues found passively as you browse appear here automatically.

Common Vulnerabilities to Test Manually

Using Burp's Proxy + Repeater + Intruder, QA engineers can find a significant portion of the most critical web vulnerabilities without any automation.

1. Reflected XSS

Find any parameter whose value appears reflected in the HTML response. In Repeater, inject:

-- Search parameter injection --
GET /search?q=<script>alert(1)</script> HTTP/1.1

-- Look for unescaped reflection in response:
<div class="results"><script>alert(1)</script></div>
-- This means XSS is present. Should be escaped to:
<div class="results">&lt;script&gt;alert(1)&lt;/script&gt;</div>

2. SQL Injection

-- Inject into login form --
POST /api/auth/login HTTP/1.1
Content-Type: application/json

{"username":"admin' OR '1'='1' --","password":"anything"}

-- A vulnerable app returns 200 with a token
-- A secure app returns 401 with "Invalid credentials"

3. IDOR (Insecure Direct Object Reference)

In HTTP History, find a request that references a numeric resource ID (e.g., /api/orders/5001). In Repeater, change the ID to a different number while keeping your own auth token. A secure app returns 403; a vulnerable app returns another user's data.

4. Auth Bypass — Removing Auth Header

In Repeater, take any authenticated request and delete the entire Authorization header. Resend. The response must be 401, not 200 with data. Surprisingly, some endpoints are protected by UI routing but not by actual server-side auth checks.

Decoder

Decoder is a utility tab for encoding and decoding data in various formats — extremely useful when analysing JWT tokens, URL-encoded parameters, and base64 data.

• Base64 decode JWT: A JWT token has three parts separated by dots. Paste the first two parts (header and payload) into Decoder and select Decode as → Base64. This reveals the algorithm and all claims in plaintext — check for sensitive data.
• URL decode: URL parameters are often double-encoded. Paste a value and decode to see the actual payload.
• HTML decode: Check if the application is incorrectly HTML-encoding data that should be stored as-is.

Burp + API Testing

Burp Suite works equally well for API testing as for web UI testing. The workflow is slightly different since there is no browser UI to navigate.

Manual API testing workflow via Proxy + Repeater:

1. Configure your API client (Postman, curl script, or the actual mobile/web app) to route through Burp's proxy (127.0.0.1:8080).
2. Send your normal API requests from the client. They all appear in Burp's HTTP History.
3. Right-click each interesting request and send to Repeater.
4. In Repeater, modify headers, body, and path parameters to test security cases.

For Postman, set the Proxy setting to Manual Proxy Configuration: 127.0.0.1:8080. For curl, use the --proxy http://127.0.0.1:8080 flag.

QA Testing Workflow with Burp Suite

Here is the structured workflow I follow when security-testing a web application or API with Burp:

1. Map the application: Browse every page and API endpoint with Intercept off and FoxyProxy on. Let Burp build a complete picture of all requests in HTTP History and the Site Map under the Target tab.
2. Identify auth endpoints: Filter HTTP History for login, token refresh, password reset, and registration flows. These are the highest priority for security testing.
3. Test each endpoint via Repeater: For each interesting endpoint: remove auth, use another user's token, inject basic payloads, test boundary conditions. Document the request/response for each finding.
4. Run Intruder on fuzzing candidates: Any parameter that filters or retrieves data is a candidate for Intruder with a basic injection payload list.
5. Review passive scanner findings: Check Dashboard → Issues for anything the passive scanner flagged during browsing.
6. Document findings: For every security issue, record: the exact HTTP request that triggers it, the response that demonstrates the vulnerability, the severity, and the remediation recommendation. Screenshots of Burp's Repeater view make excellent bug report evidence.

Tool Comparison: Burp Community vs Pro vs ZAP vs Caido

Best Practices for QA Engineers Using Burp Suite

• Always work in a test environment — never production. Burp can easily send thousands of requests via Intruder. Running this against a production environment risks service disruption, account lockouts, and legal issues. Always test against a dedicated staging or test environment.
• Scope your proxy from the start. Set your target scope before beginning any testing. An unscoped proxy captures everything — analytics, CDN traffic, third-party APIs — making it nearly impossible to find relevant security issues in the noise.
• Document every finding with request/response evidence. When you find a security issue in Repeater, immediately copy the request and response into your bug report. Developers reproduce security issues from the exact HTTP request — a description alone is often insufficient.
• Turn off FoxyProxy when not testing. Leaving browser traffic routed through Burp when Burp is not running will break all browser networking silently. Make it a habit to toggle FoxyProxy off at the end of every testing session.
• Use Burp in combination with automated scanning. Burp Community's manual testing is excellent for targeted, intelligent testing. Combine it with OWASP ZAP's automated scanning for broader coverage — they complement rather than replace each other.