Intercepting Proxies

Why it matters

Many serious web defects live in what the server trusts. If the server assumes the browser will only send order ids that belong to the logged-in user, changing that id in the proxy can reveal broken access control, A01 in the OWASP Top 10:2025 from the previous lesson, in minutes. A disabled button, a hidden field and client-side validation are only suggestions to the browser; the proxy lets you test the server, which is where security has to hold.

For the tester, the proxy turns a vague worry into repeatable evidence: the exact request, the one value you changed and the response. That is a bug report a developer can act on, and the history shows precisely what you sent, so you can show that an authorised test stayed inside its limits.

Where the proxy sits, and how to set it up safely

The proxy listens on a local address, for example 127.0.0.1:8080. You point a browser at it, and every request now travels browser to proxy to server, with each response coming back the same way. Unlike the DevTools Network panel, which records what one tab did, the proxy stands in the path and can hold a message before the server sees it.

Two set-up steps keep this safe. First, use a dedicated test browser profile, or a separate browser, that sends its traffic to the proxy, so your everyday logins and cookies never pass through it. Second, to read HTTPS the proxy ends the browser's encrypted connection itself and presents a certificate for each site, signed by its own certificate authority (CA). Trust that proxy CA in the test profile only, never system-wide or on a personal device, because a browser that trusts it accepts any certificate signed with its key, for any site. Remove it when the engagement ends.

Try it: HTTP Request Inspector

History, intercept-and-modify, and replay

The history (the History tab in ZAP; some tools call it HTTP history) lists every request and response, with filters such as method, status code and a URL pattern that matches one host, so you can find the one call you need among hundreds. Intercept-and-modify pauses a request at the proxy: you edit a header, a parameter or the body, then let it continue, so the server receives your version, not the browser's.

Replay sends a request from the history again with one value changed, so you can compare responses; in ZAP you right-click it and choose "Open/Resend with Request Editor". Replay turns "the button is greyed out" into a fact about the server. Three replays cover most first checks:

• Changed id: keep your own session and ask for another user's order or profile. The server should refuse.
• Changed role: resend, with a normal user's session, a request that only an admin should make, or set a role field from user to admin when updating your own test account. The server should refuse or ignore it.
• Changed session value: remove the session cookie, or reuse one you have logged out of. The server should answer 401 Unauthorized or send you to log in, never return the data.

Try it: HTTP Headers Parser Try it: API Authentication Tester

Passive scanning: a lead, not a verdict

While traffic flows through it, the proxy can inspect each message and raise alerts without sending anything of its own. This is passive scanning, and because it only reads traffic you were already exchanging, it is safe to leave on during ordinary testing.

An alert is a lead, not a verdict: it can be a false positive, and passive scanning misses anything that needs a request the app never made. Confirm each alert by hand before reporting it. Active scanning, where the tool sends its own crafted attack requests, is a separate, higher-risk mode that needs explicit authorisation and is beyond this lesson.

• Missing header: a response without Strict-Transport-Security or Content-Security-Policy.
• Weak cookie: a session cookie set without the Secure or HttpOnly attribute (RFC 6265).
• Leak: a token in a URL query string, or an error page that shows a stack trace.

Try it: Security Header Analyzer Try it: Cookie Analyzer

Scope and written authorisation come first

Scope is the exact set of hosts and paths you may test. In the proxy you mark only those as in scope, show only in-scope messages in the history, and limit intercept, replay and scanning to them. In ZAP you add the target to a context marked In Scope, can switch to protected mode, which blocks potentially dangerous actions such as intercepting, resending and active scanning outside the scope, and can set the passive scanner to scan only in-scope messages. The browser's other traffic, such as an analytics host or a third-party widget, usually still flows through the proxy; scope is what keeps you from changing or scanning it.

Authorisation is written permission from the system's owner that names the targets, the dates and what you may do. Test only systems you own or have explicit written permission to test; being a customer of a site is not permission. A proxy sends real, modified requests to a real server, and doing that without authorisation is not QA and is illegal in many countries. When in doubt, stop and ask.

Worked example: an access-control check by replay

You are authorised, in writing, to test your team's staging shop, and staging.shop.example is in the proxy scope. Logged in as your own test user, you open one of your orders and find its request in the history. In the request editor you change only the order id to one owned by a second test user, keep your own session cookie, and resend.

The secure result is 403 Forbidden or 404 Not Found: the server checks that the order belongs to the caller. A 200 OK with the other user's order is broken access control, an insecure direct object reference (IDOR), and you already hold the exact request and response for the bug report.

GET /api/orders/1042 HTTP/1.1
Host: staging.shop.example
Cookie: session=<your own test session>

# Replay with one change: an order id that is not yours
GET /api/orders/1043 HTTP/1.1
Host: staging.shop.example
Cookie: session=<your own test session>

# Secure response:   403 Forbidden  or  404 Not Found
# Broken access control: 200 OK with another user's order

Try it: API Request Builder

Frequently asked questions

References

• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• NIST SP 800-115: Technical Guide to Information Security Testing and AssessmentNIST · 2008How to plan and run security assessments: review, target identification, vulnerability validation and reporting.
• OWASP Top 10:2025OWASP Foundation · 2025The ten most critical web application security risks, with how to test for and prevent each.
• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.