A city web engagement begins by placing an intercepting proxy in the browser path. What is the primary reason that step matters?
Select an answer to reveal the explanation.
Short Explanation
An intercepting proxy is like putting a transparent control tower between the browser and the app — you can see the planes and, when allowed, adjust the flight plan. It is not about page-speed bragging or picking a logo. You use it to understand and carefully reshape HTTP traffic under RoE.
Full Explanation
Intercepting proxies let testers inspect and modify HTTP(S) requests and responses during authorized tests. Placing a proxy in the browser path at the start of a city web engagement establishes the primary lab for observing parameters, cookies, tokens, and server responses that underlie CPTS-style web application judgment—without which many authorization and injection tests lack visibility.
Proxies are not primarily page-load accelerators for load testing. A vendor logo is not required report evidence. Browser proxies do not replace authentication or session handling; they help analyze those mechanisms.
Exam caveat: TLS interception must stay within RoE and client constraints; document limitations when pinning or enterprise TLS controls block full intercept. CPTS web work begins with disciplined request visibility.
Operational check: confirm proxy trust/install steps approved for the civic test browsers, verify HTTPS interception works for in-scope hosts, and capture baseline authenticated request flows before mutating inputs. Keep sanitized proxy logs as engagement artifacts showing request/response evidence without storing unnecessary citizen personal data from the city portal.