A municipal API reflects arbitrary Origin values in Access-Control-Allow-Origin while also allowing credentials. Why is this dangerous?
Select an answer to reveal the explanation.
Short Explanation
CORS is the bouncer deciding which websites may read your stuff with the user's cookies. If every Origin gets a VIP pass plus credentials, hostile pages can siphon data. Reflecting arbitrary origins with credentials is a serious misconfig.
Full Explanation
Reflecting arbitrary Origin values in Access-Control-Allow-Origin while allowing credentials enables browser-based cross-origin data theft. A municipal API that mirrors any Origin with Access-Control-Allow-Credentials true tells victim browsers it is acceptable for attacker origins to read credentialed responses—defeating the same-origin boundary for citizen data APIs.
CORS is not limited to offline PDF exports. Reflecting origins does not upgrade HTTP to HTTPS. ACAO reflection is not required for SameSite cookies to function.
Exam caveat: ACAO must be an explicit allowlist, never a reflected echo, when credentials are allowed. CPTS CORS findings hinge on the credentials + reflection combination.
Operational check: verify ACAO against an evil origin with credentials mode in a browser test within RoE, replace reflection with a strict civic allowlist, retest trusted frontends still work, and monitor CORS failures after the change. CORS allowlists for municipal APIs should be reviewed whenever front-end origins change; avoid wildcards and reflection in credentialed modes permanently. Credentialed CORS misconfiguration is a direct browser data-theft path for municipal APIs. Cite the control owner in the civic remediation plan.