mitmproxy for FDEs: when API docs and real traffic disagree, put a proxy in the middle

On a client site, API docs often say authentication failures return 401 while your app keeps getting a 200 with an error buried in the body. Arguing about the spec rarely settles it. FDE Times' Oct 17 tools guide argues the evidence is on the wire: put mitmproxy between the two sides and read the real request and response together.

The open-source HTTPS proxy (MIT licence) acts as the server to the client and as the client to the server. For TLS it ships a certificate authority and generates certificates on the fly, so the client device must trust that CA—and FDEs should get written permission, use a test environment, and remove the CA when done. The toolkit has three programs: interactive mitmproxy, browser UI mitmweb (useful when screen-sharing with the customer's engineers), and scriptable mitmdump for addons.

Prefer explicit proxy mode when you can configure the client. Use local capture when the app has no proxy setting, and reverse proxy when you cannot touch the client but can sit in front of a service (for example webhooks). An addon that flags 200 responses whose body contains "error" turns a one-off finding into a repeating check; scripts loaded with mitmdump -s reload when you edit them.

For FDE candidates, the piece frames a clean interview story—symptom, evidence, fix—rather than just naming a tool. Captured traffic may hold tokens and customer data, so it should never be pasted into tickets or chat.