Articles

Burp Suite Interview Questions: Request Context, Session State, and Evidence-Based Findings

Prepare for Burp Suite interview questions by tracing request context, session changes, redirects, and evidence that supports a reproducible security finding.

Burp Suite interview questions become interesting when a request appears to prove a defect but its context does not support that conclusion. You change a resource ID, press Send, and receive 200. Was the response private data, a login page, a cached representation, or the result of a session rule silently restoring the original user?

A strong answer follows the request from captured intent to transmitted identity to application outcome. Record the effective actor and the relevant business policy before interpreting the result. A tool can help reproduce behavior; it cannot decide what an account should be allowed to do.

This article separates official PortSwigger tool behavior from original defensive exercises and interview guidance. The fixtures below are synthetic; no real application was tested.

What context belongs to a captured request?

A request context is the combination of destination, message, effective identity and application state needed to interpret one exchange. It includes the scheme, host, port, path, method, parameters, authentication material, content type, relevant prior actions and observation time. Two requests with the same path can represent different security experiments.

Official tool behavior: Burp Repeater lets you modify and resend HTTP or WebSocket messages, maintain separate tabs and inspect their modification history. Use that capability to retain a known-good control beside the variation. Giving a tab a descriptive name makes its purpose visible, but does not guarantee that its session remains the same.

Our original exercise uses a fictional invoice application. Test account A owns invoice 17; B owns invoice 29. The supplied policy allows each account to read its own invoice and denies access to the other's. This is an exercise contract, not a universal claim that invoice systems cannot support sharing or delegated access.

Record the control as GET /invoices/17, account A, expected owner A and an invoice-shaped JSON response. Also record the service destination, whether a macro runs, and whether redirects are followed. Those details make the subsequent comparison interpretable.

A useful interview explanation is: “I would preserve the successful owner request, verify the second account independently, and then change the ownership relationship while retaining the rest of the relevant context.” If the interviewer changes the policy to shared organization access, revise the expected result before calling the behavior a vulnerability.

Does scope filtering prevent every outgoing request?

Official distinction: Scope settings include target scope and separate out-of-scope request handling. Selecting a target helps tools classify destinations. The explicit option to drop all out-of-scope requests controls blocking, using either suite scope or a custom scope. A quiet display is therefore insufficient evidence that no external request was issued.

For a supplied lab, define the permitted service and paths before replaying anything. A static asset host or identity provider can appear in ordinary browser traffic while remaining outside the permitted testing boundary. Decide whether such dependencies may receive ordinary navigation traffic; do not assume that their appearance grants permission to test them.

Consider an exercise where /account returns a redirect to an external login service. A history filter can hide that destination while Repeater follows it. The relevant question is which redirect policy and blocking settings were active, not whether the out-of-scope row was visible in one panel.

The interview takeaway is operational: scope membership, logging visibility, interception and outgoing-request prevention are different controls. Explain which one you checked and what evidence would confirm its effect. Avoid describing a target label as a universal network boundary.

Why can a replay return 200 without authenticated access?

Official behavior: Repeater's settings offer redirect policies such as never, on-site only, in-scope only and always. The documentation also describes cookie processing during redirects and automatic Content-Length updates. Global settings can be overridden for an individual tab, so compare the tab configuration when results disagree.

Our original expired-session trace is:

1. GET /invoices/17 with expired session A
   302, Location: /login
2. GET /login after following that redirect
   200, Content-Type: text/html, page kind: login

The final 200 belongs to /login. It does not prove that /invoices/17 returned invoice data. Preserve the first exchange, each redirect destination and the final response's meaning. If an automatic login macro also runs, record that additional sequence separately.

Status, response length and elapsed time are clues rather than a complete oracle. A short generic denial and a short empty invoice can have similar sizes. A server can return a friendly error page with 200. Conversely, a legitimate authorization denial may use 404 to avoid revealing whether an object exists. Compare expected fields and the intended endpoint, not just a status-code threshold.

When the response changes after editing a body, confirm that encoding and content type still match the application contract. An invalid JSON request that receives 400 has not exercised the same business operation as the valid control. Automatic length correction is useful context; it does not correct an incorrect payload schema.

How can session automation invalidate a two-account test?

Official mechanics: Session settings describe a shared cookie jar, session handling rules and macros. Rules can update outgoing requests, and macros can perform prerequisite exchanges. The cookie jar respects domain and path scope; having a stored cookie does not mean every tool and request will automatically use it without the relevant configuration.

Separate three observations: the credentials shown in the editor, the credentials sent after rule processing, and the actor the application recognized. The effective actor is the identity that actually reached the authorization decision. It may differ from the actor you intended to use.

In our exercise, you paste B's session into an A-originated invoice request. A rule then adds A's current session from the jar. The response contains invoice 17, but the application recognized A. That result is consistent with the supplied policy. It does not establish that B read A's data.

Official evidence surface: Logger records traffic generated by Burp tools and extensions, including modified requests. Proxy HTTP history covers traffic from a browser proxied through Burp. Inspecting only browser history can therefore miss the replay or a rule-induced change that matters to the experiment.

Keep account-specific test tabs and their rule context understandable. Do not disable every session mechanism merely because automation exists; some legitimate workflows require a current anti-forgery token or a prerequisite action. Instead, establish which values may change and verify that the effective actor remains the intended one.

What controls make an authorization finding defensible?

Official testing approach: PortSwigger's horizontal-access tutorial uses two accounts with equivalent privileges and compares behavior under their respective sessions. The critical interpretation still depends on the application's intended policy and the data actually returned.

The following is our original evidence matrix. “Invoice response” means the expected invoice identifier and owner fields were present, rather than an arbitrary 200 response.

Trial	Intended / effective actor	Observation	Supported conclusion
A requests invoice 17	A / A	Invoice 17, owner A	Valid owner control
B requests invoice 29	B / B	Invoice 29, owner B	B has a working independent session
B requests invoice 17	B / B	Denial, no private invoice fields	This route enforces the supplied policy for this case
B requests invoice 17 after a rule rewrite	B / A	Invoice 17, owner A	Identity contamination; B access remains unproved

Our offline predicate checks distinguish these cases from a deliberately flawed positive control that returns any existing invoice regardless of actor. They validate the teaching matrix, not Burp's runtime or an actual backend. A successful positive control helps establish that the fixture can recognize the property it claims to examine.

If the real lab instead returns A's private invoice under verified actor B, preserve a minimal reproduction and confirm freshness. A subsequent request using the same contaminated cache could repeat the observation without independently proving the origin server's policy. Record whether the suspected failure is authorization, cache isolation or another boundary.

A negative result has limited scope. One protected read route does not establish that update, export, batch retrieval and administrative routes share the same authorization implementation. State what was tested and what remains untested rather than turning a successful control into a system-wide verdict.

How do you turn a response into a reviewable finding?

Official reporting model: Manual issues can attach selected requests and responses as evidence and record severity separately from confidence. PortSwigger documents these reporting facilities for Professional. The distinction matters even when you write a report outside that edition: impact and certainty answer different questions.

For our fictional policy, a reviewable finding would state: “Authenticated test account B could retrieve the private fields of invoice 17 owned exclusively by A.” It would identify the tested service, route, method, effective actor, successful B-own control, unauthorized exchange and exact private fields. Merely writing “IDOR, high severity,200response” leaves the essential claim unsupported.

Record the expected boundary, observed behavior and reproduction preconditions. If the observation requires an expired session, a specific cache state or a prior workflow step, include that dependency. Replace session values with clearly marked placeholders in shareable evidence while keeping the internally approved original evidence accessible to the authorized reviewer.

Confidence rises when a controlled repeat produces the same unauthorized business result under the verified actor and competing explanations have been tested. Severity depends on accessible data, permitted actions and business consequences. A reproducible leak of a low-sensitivity public field can be certain without being severe; a plausible broad financial impact can remain tentative while evidence is incomplete.

Explain remediation at the boundary that failed. An object read should enforce the supplied ownership or delegation policy on the server. The regression should include A-own success, B-own success and B-other denial with current independent sessions. A frontend-hidden button or a different identifier format does not demonstrate that the server now checks authorization.

For follow-ups, distinguish observations from proposed next experiments. If a scanner label suggests a wider issue, say which property the current evidence supports and what controlled test would extend it. That makes your uncertainty useful instead of disguising it with stronger language.