Practical task from a QA training programme module on tools for testing a web application — intercepting, decrypting, filtering and modifying live browser traffic through a man-in-the-middle debugging proxy.
What this skill is called. This is HTTP(S) traffic interception — also known as proxy debugging, traffic sniffing, or MITM proxy analysis. In the standard Mobile Testing Mind Map it is the branch "Working with sniffers (Fiddler/Charles)". It is not API testing, though the two are often confused — see What this discipline actually is below.
| Tool | Fiddler Classic v5.0 |
| Browser | Google Chrome |
| OS | Windows 10 (64-bit) |
| Proxy | 127.0.0.1:8888 (system proxy) |
| Target | google.com |
| Tasks completed | 6 of 6 |
| Trainee | Ashakuzzaman Odree |
Screen recording covering the interception, breakpoint and response-modification steps:
▶ https://youtu.be/RAsdhGQba_8
Learn to work with Fiddler. Using the Fiddler program, you need to:
- Set up interception of HTTP(S) traffic on your computer. Install certificates.
- Decrypt HTTPS traffic. Enable the TLS 1.2 protocol.
- Set up a filter for Google site traffic only.
- Replace the text of the search query being sent on the Google website (enter
Test1in the search field, getTest2as the output).- Change the query so that on the search results page, the size of the Google logo is increased 5×.
- Analyse the headers in the query and understand what they are responsible for.
Result: step-by-step instructions with a description of all steps + video for 3–4 steps. Describe the headers in item 6.
| # | Task | Documentation | Outcome |
|---|---|---|---|
| 1 | Proxy setup + root certificate | 01-PROXY-SETUP-AND-CERTIFICATES.md |
✅ |
| 2 | HTTPS decryption + TLS 1.2 | 02-HTTPS-DECRYPTION-AND-TLS.md |
✅ |
| 3 | Host filtering (two methods) | 03-TRAFFIC-FILTERING.md |
✅ |
| 4 | Request breakpoint — Test1 → Test2 |
04-REQUEST-INTERCEPTION.md |
✅ |
| 5 | Response breakpoint — logo 5× | 05-RESPONSE-MODIFICATION.md |
✅ |
| 6 | HTTP header analysis (12 headers) | 06-HTTP-HEADERS-REFERENCE.md |
✅ |
It is easy to file this under "API testing". It isn't, and the distinction is worth getting right in an interview.
| Traffic interception (this repo) | API testing | |
|---|---|---|
| Position | Sits between an existing client and its server | Replaces the client entirely |
| Tools | Fiddler, Charles, Burp Suite, mitmproxy | Postman, REST Assured, SoapUI, curl |
| You observe | What the real app genuinely sends and receives | What an endpoint returns to a request you composed |
| Typical question | "Is the client sending what I think it is?" | "Does this endpoint behave to contract?" |
| Finds | Client/server contract mismatches, exposed data, missing security headers, trust placed in client-side validation | Wrong status codes, schema violations, broken business logic |
Both are black-box techniques against the same HTTP layer, and they overlap — but interception is the only one that shows you the real client's actual behaviour, including the requests nobody documented.
The standard Mobile Testing Mind Map used across the industry lists "Working with sniffers (Fiddler/Charles)" as its own top-level branch, covering:
- how HTTP requests behave through a proxy server, with text, image, audio and video payloads
- successful connection establishment, data transmission and response handling
- correct handling of changed proxy settings — address, port, authentication
- secure proxy connections using SSL/TLS
- handling of unavailable proxies, authentication errors and connection failures
- correct switching between multiple proxy servers without data loss
- verification that confidential data is not transmitted without encryption
That final item is the point of the whole exercise. Everything else is technique.
| Capability | Evidenced by |
|---|---|
| Understands TLS, MITM and certificate trust | Task 1 — knowing why the root certificate must be trusted, and why the store matters |
| Understands protocol negotiation | Task 2 — knowing why a site works without the proxy and breaks with it |
| Can isolate signal from noise | Task 3 — filtering, and knowing Use Filters gates everything |
| Can bypass client-side validation | Task 4 — the core technique for proving server-side validation is missing |
| Can force UI states the backend won't produce | Task 5 — error branches, empty states, malformed payloads |
| Reads the protocol, not just the UI | Task 6 — 12 headers explained by function, not definition |
fiddler-https-traffic-interception/
├── README.md ← you are here
├── docs/
│ ├── 01-PROXY-SETUP-AND-CERTIFICATES.md ← proxy config + root cert, and why it's needed
│ ├── 02-HTTPS-DECRYPTION-AND-TLS.md ← decryption + the TLS 1.2 protocol list
│ ├── 03-TRAFFIC-FILTERING.md ← QuickExec and Filters tab methods
│ ├── 04-REQUEST-INTERCEPTION.md ← request breakpoint, Test1 → Test2
│ ├── 05-RESPONSE-MODIFICATION.md ← response breakpoint, logo 5×
│ └── 06-HTTP-HEADERS-REFERENCE.md ← 12 headers + what testers manipulate
└── files/
└── Fiddler_Task_Steps.docx ← original submission, unmodified
Client-side validation is a usability feature, not a security control. A request breakpoint is the fastest way to demonstrate that to a developer who believes a maxlength attribute is protection.
A missing security header is a real defect. Reading response headers is how X-Frame-Options absences, X-Powered-By disclosures and missing nosniff directives get found — none of which are visible anywhere in the UI.
The root certificate is a genuine risk. DO_NOT_TRUST_FiddlerRoot is named that way for a reason. It belongs on a test machine, and it should be removed when the work is done.
The mobile counterpart of this task — intercepting traffic from a physical phone with Charles Proxy — is in charles-proxy-mobile-traffic-interception.
Prepared by Ashakuzzaman Odree · August 2026