auditing-cors-and-cross-origin-trustlisted

# Auditing CORS and cross-origin trust: when an attacker's origin is trusted The request origin is fully attacker-controlled: any site the victim visits sets it. Cross-origin sharing is safe only because the server decides, per origin, whether to hand back an authenticated response, and a browser enforces that decision. The bugs are all the same shape: the server trusts the origin it was told. It reflects whatever origin arrived and pairs it with credentials, so any site reads the victim's authenticated data; it matches an allowlist by substring, so a lookalike passes; it treats the origin as proof of who is calling. The client-side mirror is a message handler that acts on a posted message without checking where it came from. You find these by reading the code that builds the allow-origin decision, or handles a cross-window message, and asking whether an attacker-set origin is trusted. ## When to use - The code sets cross-origin response headers, statically or by computing them from the request origin. - An access, authorization, or request-forgery decision is made by looking at the origin or referer. - Client code receives cross-window messages and acts on their data. ## Scope check Test cross-origin behavior only against applications you own or are authorized to assess, from a test origin and test accounts. A confirmed credentialed cross-origin read exposes real user data, so coordinate. If you can't name the authorization, stop. ## The loop 1. **Map the decision poi