Using Burp Suite for QA: A QA Guide (2026)

TL;DR

Using Burp Suite for QA means placing its local proxy between an authorized client and test environment, capturing a known-good request, and replaying controlled changes in Repeater. Use it to validate HTTP behavior, APIs, access control, sessions, WebSockets, and input handling, with strict scope and cautious scanning.

Key Takeaways

• Use Burp only on explicitly authorized targets and define scope before capturing or scanning.
• Start with Proxy history for evidence, then send one request to Repeater for controlled mutations.
• Test server-side authorization by replaying requests across roles, not by trusting hidden UI controls.
• Preserve raw requests and responses to reproduce API, cache, redirect, cookie, and encoding defects.
• Treat active scanning as a scoped test-environment activity with seeded accounts and recovery plans.
• Route Playwright or curl through the local Burp listener when an automated flow is the best traffic generator.
• Report the minimal reproducible exchange, impact, role, build, and remediation verification result.

A practical approach to using Burp Suite for QA gives testers precise visibility into the HTTP and WebSocket traffic that sits between a browser, mobile client, or API tool and the server. The core workflow is simple: capture a legitimate request through Burp Proxy, understand its baseline behavior, send it to Repeater, change one variable, and compare the response plus server-side effect.

That workflow helps reproduce functional defects, diagnose integration failures, and find security-relevant authorization or validation gaps before release. It also carries responsibility. Interception and active testing must be limited to systems, accounts, and methods the team has explicitly authorized. This guide focuses on safe staging workflows, current Burp capabilities, runnable client configuration, and evidence that a QA engineer can hand to developers.

TL;DR

Start with Intercept off so normal traffic flows into history. Add the test host to scope, filter noise, and make one controlled change at a time.

1. Define scope before using Burp Suite for QA

Before opening a target, write down the test boundary. Include hostnames, ports, API base paths, account roles, allowed HTTP methods, test window, prohibited actions, data classification, rate limits, and a contact who can stop the exercise. Authorization for functional testing does not automatically authorize intrusive scanning, account lockout tests, or access to another customer's data.

Use a dedicated test environment and seeded accounts whenever possible. If production validation is specifically approved, favor passive observation and narrow manual checks. Do not active-scan production merely because the host is reachable from the proxy. Active checks can submit forms, create records, trigger notifications, consume quotas, or exercise payloads that alter data.

Burp's target scope is both a safety control and a productivity tool. Add the exact application origins and exclude logout, destructive administration, third-party analytics, identity-provider domains you do not own, and other out-of-scope services. Configure Proxy history to avoid logging out-of-scope items when appropriate. The default desktop proxy listener uses the loopback interface on port 8080; keep listeners on loopback unless a reviewed use case requires another interface.

Create a fresh Burp project for a release or investigation when retained traffic could otherwise mix environments. Project files contain sensitive requests, responses, tokens, and personal data. Store them only in approved encrypted locations, apply retention rules, and never attach an unredacted project to a public issue.

A good first checkpoint is simple: the browser loads the staging site through Burp, only in-scope traffic appears in history, and the application still behaves normally.

2. Configure the browser, TLS, and proxy safely

The easiest setup is Burp's built-in browser because it is already configured for the proxy and Burp CA. An external browser or API client must use the listener, commonly 127.0.0.1:8080, and trust Burp's CA for HTTPS inspection. Install that CA only in a dedicated test browser profile or test trust store. Do not add a QA interception CA to an organization-wide production trust store.

For command-line reproduction, export Burp's CA certificate and convert it to PEM if it was exported as DER. Then tell curl to use both the proxy and that CA. The commands are real and avoid disabling TLS verification.

openssl x509 -inform DER -in burp-ca.der -out burp-ca.pem

curl --proxy http://127.0.0.1:8080 \
  --cacert burp-ca.pem \
  --request GET \
  --header 'Accept: application/json' \
  'https://staging.example.test/api/orders/order-1001'

If you export PEM directly, skip the conversion. Do not use curl -k as the routine solution because it hides unrelated certificate problems. If traffic does not appear, verify the listener is running, the client proxy is correct, the target is not covered by a bypass rule, and a VPN or system proxy is not taking precedence.

Certificate pinning in mobile apps prevents ordinary interception by design. Use an approved debug build with pinning disabled or a test trust configuration supplied by developers. Do not improvise a bypass against an unapproved build. HTTP/2 and WebSockets are supported by Burp, but client behavior can differ when proxied, so record whether a defect reproduces both through and outside the proxy.

3. Capture a baseline with Proxy history

With interception off, perform one clean user journey and locate its requests in Proxy history. Filter by target scope, method, MIME type, status, or search term. The objective is to understand the request chain without pausing every asset. A login action might include a configuration request, anti-forgery token, credential post, redirect, session cookie, and profile fetch. Missing any link can lead to the wrong diagnosis.

For the request under test, record:

• Method, scheme, host, path, and query.
• Content type, accept header, origin, and referer where relevant.
• Authentication, cookie, anti-forgery, idempotency, and correlation headers.
• Request body encoding and repeated parameter behavior.
• Status, redirect location, cache headers, and response media type.
• Final browser-visible result and server-side state.

Use the message inspector to view parsed parameters, headers, cookies, and body alongside raw bytes. The raw view matters for duplicated headers, ambiguous delimiters, line endings, multipart boundaries, and encoding bugs. Search the history for a correlation ID to connect front-end behavior to service logs.

Save a baseline request to Repeater before editing. Label tabs by scenario, role, and resource, such as viewer reads own order. Avoid using a large noisy history entry as the only defect evidence. A small baseline plus one controlled variant is easier to review and reproduce. For foundational API cases, pair this workflow with API security testing basics.

4. Use Repeater for controlled functional and API tests

Repeater lets a QA engineer send the same request repeatedly while changing one detail. This is ideal for isolating whether validation lives in the browser or server, whether a header affects representation, and whether an API handles boundaries consistently. Send the baseline from Proxy history to Repeater, confirm it still succeeds, then mutate one dimension.

High-value functional variations include:

After each send, inspect both response and application state. A 400 is not enough if a partial record was created. A 200 is not enough if the body uses the wrong account or a cache served stale data. Use Repeater groups or clear labels to keep related cases together.

Do not fire large automated payload lists at this stage. Controlled mutation produces better evidence and reduces risk. Once a rule is understood and authorized for broader coverage, Intruder or Scanner may help, but the manual oracle should exist first. API idempotency testing offers deeper patterns for retry-safe operations.

5. Test authorization across roles and object ownership

Hidden buttons and disabled inputs are client-side presentation, not authorization. Burp makes it easy to prove what the server enforces. Capture the same permitted operation for two seeded roles, such as an administrator and a viewer. Then replay carefully selected requests with the other role's session and object identifiers. The expected result comes from the access-control matrix, not from the UI.

Use test-owned records. Never substitute a real customer's identifier to see what happens. Create Resource A owned by User A and Resource B owned by User B, then exercise read, update, delete, export, and nested-resource actions according to authorization. Check response codes, bodies, timing only as supporting evidence, and persistent state. A masked error body is not sufficient if the forbidden update occurred.

A practical matrix includes:

• Anonymous versus authenticated.
• User versus peer user.
• User versus elevated role.
• Active versus suspended or expired account.
• Same tenant versus another seeded tenant.
• Direct object endpoint versus search, export, attachment, or batch endpoint.

Use separate Repeater tabs or sessions for roles and label them clearly. Burp's session-handling capabilities can help maintain authentication, but verify which account is active before sending a state-changing request. Redact tokens from evidence while preserving enough header names and role metadata for reproduction.

If changing only an object ID exposes another seeded user's data or action, report the exact authorization rule and affected endpoint. Avoid claiming broad impact beyond what the controlled test proves. For dedicated injection checks on query-backed APIs, follow SQL injection testing guidance in an explicitly approved environment.

6. Diagnose sessions, cookies, CSRF, caching, and redirects

Burp is valuable for problems that cross several HTTP features. For session tests, inspect cookie attributes such as Secure, HttpOnly, SameSite, domain, path, and expiration. Verify session rotation after login or privilege change, invalidation after logout, and behavior after password reset or administrative revocation. Use seeded accounts and coordinate lockout cases because repeated failures can affect shared environments.

For anti-forgery controls, compare a legitimate state-changing request with one missing the token, carrying a token from another session, or using an untrusted origin, according to the application's documented defense. Do not assume that the presence of a token proves it is validated. Check the server-side state after rejection.

Caching defects often become obvious in raw responses. Test whether authenticated or personalized responses have appropriate cache directives and vary on the headers that actually change content. Repeat requests across seeded users and verify no shared cache returns another user's representation. Examine ETag, Last-Modified, conditional requests, and 304 behavior for functional correctness as well as privacy.

Redirect chains can leak tokens or accept unsafe destinations. Follow each Location, distinguish server redirects from client navigation, and verify relative versus absolute URL handling. Repeater does not automatically behave exactly like a browser in every flow, so reproduce browser-dependent behavior through Proxy history as well.

Keep these checks evidence-led. A missing header may be a hardening observation, while a reproducible cross-user cache response is a functional and security defect. Severity follows demonstrated impact and the organization's policy.

7. Test JSON, XML, multipart, GraphQL, and WebSockets

Burp is protocol-flexible because it works at the HTTP message layer. For JSON, change types as well as values: number to string, value to null, omitted key, unknown key, empty array, repeated business identifier, and deep but reasonable nesting. Confirm the API returns the documented media type and a stable error object without leaking internals.

For XML and SOAP, preserve namespaces and content types, inspect raw bytes, and change one schema dimension at a time. Use an XML-aware tool or automated assertion for full schema validation because Repeater itself is best for transport and controlled message changes. The XML API testing guide explains namespace, XSD, SOAP Fault, and safe parser coverage.

Multipart tests should preserve boundary syntax. Start from a browser-generated valid upload, then vary filename encoding, declared media type, empty file, size boundary, duplicate part names, and metadata consistency. Use harmless test files, never malware, unless a specialized isolated exercise explicitly authorizes it.

For GraphQL, capture legitimate operations, vary variables and authorization context, and verify field-level access. Broad introspection or automated enumeration needs scope approval. For WebSockets, Burp Proxy provides a WebSockets history and interception rules. Record the upgrade request, authentication, subprotocol, frame direction, message format, reconnect behavior, and server state. Test whether a message accepted from the UI is also correctly authorized when replayed or modified.

Never infer that every frame can be resent safely. A payment, deployment, or administrative message may have irreversible effects. Use dedicated records and understand the server's idempotency behavior before replay.

8. Use Intruder, Decoder, Comparer, and Sequencer purposefully

Burp's supporting tools solve different QA problems. Intruder automates payload placement across requests. Decoder transforms common encodings and hashes for inspection. Comparer highlights byte-level or word-level differences. Sequencer analyzes the randomness characteristics of token samples. Use each only when the QA question requires it.

Intruder is helpful for a small boundary set, enumeration of documented enum values, or consistent test IDs. Configure one insertion point first, keep request rate within the agreed limit, and add a recognizable test header or value. Do not launch large generic lists at a shared system. Repeater remains better when each response needs reasoning or when the operation changes state.

Decoder can reveal that a value is URL encoded, Base64 encoded, or represented as hex. Decoding is not decryption, and a readable token is not automatically a vulnerability. Treat decoded tokens as secrets, redact them, and verify signature or server behavior through an appropriate test rather than editing blindly.

Comparer is excellent for paired role responses, old versus new build behavior, and cache variants. Normalize known dynamic values only when they obscure the relevant difference. Sequencer can support analysis of session or anti-forgery token samples, but statistical results need sufficient clean samples and expert interpretation. A QA engineer should not report token predictable from a tiny or contaminated capture.

The principle is economy: pick the smallest tool that answers one test question and produces reproducible evidence.

9. Run Burp Scanner carefully and verify findings

Burp Scanner is available in supported commercial Burp offerings, not as the full active scanner in Community Edition. It can crawl and audit applications, and modern configurations can parse API definitions, SOAP WSDL definitions, and GraphQL information when enabled. Capabilities and licensing can change, so confirm the installed edition and current PortSwigger documentation before planning a pipeline.

Before an active scan:

1. Confirm written authorization and target scope.
2. Use a recoverable test environment and seeded low-privilege accounts.
3. Exclude logout, destructive routes, third-party hosts, and costly actions.
4. Configure authentication and verify the recorded login stays valid.
5. Choose scan checks and crawl depth appropriate to the technology and risk.
6. Set resource limits and notify environment owners.
7. Take a state baseline and define cleanup.

Start with passive review and a crawl when risk is uncertain. Active audit checks send attack-like inputs and can create side effects. Scan configurations allow selection by activity level and individual issue type. A test environment is still not a license to ignore operational impact.

Treat findings as hypotheses. Reproduce the minimal request in Repeater, verify the response and side effect, remove false positives, and map the issue to the affected role and asset. Retest after the fix using the original request plus a nearby regression case. Scanner coverage does not replace access-control matrices, business logic tests, or code review.

10. Route Playwright and API clients through Burp

An automated client can generate a complex authenticated journey while Burp records the exchange. This is useful for diagnosing one unstable flow or building a precise traffic corpus. It is not a reason to proxy the whole regression suite permanently, because the extra layer changes performance and can increase storage of secrets.

The following Playwright test uses documented proxy and context APIs. Start Burp's listener first. For a dedicated test environment, importing the Burp CA into the browser trust store is preferable. ignoreHTTPSErrors is shown only for a controlled interception profile.

import { test, expect, chromium } from "@playwright/test";

test("capture an order journey through Burp", async () => {
  const browser = await chromium.launch({
    proxy: { server: "http://127.0.0.1:8080" },
  });
  const context = await browser.newContext({
    ignoreHTTPSErrors: true,
    extraHTTPHeaders: { "x-qa-run-id": "burp-order-1001" },
  });
  const page = await context.newPage();

  await page.goto("https://staging.example.test/orders/order-1001");
  await expect(page.getByRole("heading", { name: "Order order-1001" })).toBeVisible();

  await context.close();
  await browser.close();
});

Use environment variables for base URLs and credentials in real tests. A distinctive safe run header makes filtering easier, but add it only if the server and gateway permit it. Remove interception breakpoints during automated execution or the test will appear hung.

Burp's REST API can integrate external tools when enabled. Bind it to loopback, require an API key, and use the interactive documentation exposed by the installed Burp version rather than copying undocumented endpoints. Treat the API key and project data as secrets.

11. Operationalize using Burp Suite for QA and defect reporting

Operationalizing using Burp Suite for QA does not mean scanning every build. Define repeatable use cases: HTTP diagnosis during feature testing, authorization matrices for high-risk endpoints, focused release scans in an isolated environment, and regression replay for confirmed defects. Link each use case to ownership, scope, edition, environment, and retention.

A strong Burp defect contains:

• Environment, build, timestamp, and test account role.
• Preconditions and test-owned object identifiers.
• Baseline request and expected behavior.
• Minimal changed request and actual behavior.
• Relevant response and verified server-side effect.
• Impact stated at the level demonstrated.
• Redacted evidence and correlation IDs.
• Cleanup performed and suggested regression test.

Export only the messages needed for reproduction. Remove session cookies, authorization headers, personal data, and secrets. If a value must remain structurally visible, replace it consistently so relationships still make sense. Mention whether the issue reproduces outside the proxy, because proxy-specific TLS or HTTP-version behavior can matter.

For CI, use the product's documented DAST or REST integration for the installed edition, keep API keys on loopback and in secret storage, and configure scan scope as code where supported. A merge gate should use verified severity and policy, not raw untriaged issue count. Preserve sanitized scan configuration and evidence so a changed result can be explained.

Interview Questions and Answers

Q: How do you use Burp Suite as a QA engineer?

I proxy an authorized user journey, filter to the target scope, and select a known-good request from HTTP history. I resend it in Repeater while changing one value, role, or header and verify both response and server-side state. I use scanning only with explicit approval and manually reproduce findings before reporting them.

Q: What is the difference between Proxy and Repeater?

Proxy captures traffic flowing between a client and server and can intercept it. Repeater sends a selected request repeatedly under manual control. Proxy helps discover the real exchange, while Repeater isolates and proves a specific behavior.

Q: How would you test broken object-level authorization?

I create two seeded users and objects they own, capture a permitted request for one, then replay the relevant endpoint with the other user's session and the test-owned object ID. I verify response content and persistent state for read and write cases. I never use real customer identifiers.

Q: How do you handle HTTPS traffic in Burp?

I use Burp's built-in browser or install its CA only in a dedicated test trust store. External clients point to the loopback proxy listener and trust that CA. I avoid disabling TLS verification as a routine practice and use an approved debug build when certificate pinning is present.

Q: Can Burp Scanner replace manual security testing?

No. Scanner can find many technical patterns, but it does not understand all authorization, workflow, and business invariants. I scope it carefully, verify findings in Repeater, and combine it with role matrices, functional tests, and review.

Q: How do you prevent Burp testing from harming an environment?

I document scope, exclude destructive and third-party routes, use seeded accounts, limit rates and checks, coordinate the window, and define cleanup. Active scans run in recoverable test environments. Project files and evidence are treated as sensitive data.

Q: How can Playwright work with Burp?

Playwright launches a browser with its proxy server set to the Burp listener. A dedicated context uses the test environment trust setup and can add a safe run ID for filtering. Interception must not pause the automated flow, and the proxy is used for targeted diagnosis rather than routine performance measurement.

Common Mistakes

• Testing a host without explicit authorization or a written scope.
• Leaving Intercept on and mistaking a paused request for an application timeout.
• Capturing every third-party domain and retaining unnecessary sensitive traffic.
• Changing several parameters at once, which destroys causal evidence.
• Reporting a scanner item without manual reproduction and impact validation.
• Trusting hidden UI controls instead of testing server authorization.
• Using production customer IDs for object-level authorization checks.
• Disabling TLS verification instead of trusting the dedicated test CA.
• Running active scans against state-changing flows without cleanup.
• Sharing unredacted Burp projects, session tokens, or request exports.
• Measuring application performance through an interception proxy.

The most effective Burp workflow is deliberate and narrow. Capture reality, isolate one hypothesis, prove the business outcome, and preserve only safe evidence.

Conclusion

Using Burp Suite for QA turns opaque browser and API behavior into inspectable, reproducible HTTP evidence. Proxy and Repeater cover most day-to-day value, while Comparer, Decoder, WebSockets history, automation, and scoped Scanner use extend the workflow for specific risks.

Begin with one authorized staging journey, add the host to scope, capture a clean baseline, and reproduce one boundary or role case in Repeater. Document the request, response, and final state, then convert confirmed behavior into a durable automated regression where practical.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Using OWASP ZAP for QA: A QA Guide (2026)
• Testing for CSRF: A QA Guide (2026)
• Testing for IDOR: A QA Guide (2026)
• Testing for SQL injection: A QA Guide (2026)
• Testing for XSS: A QA Guide (2026)
• A/B test validation: A Complete Guide for QA (2026)