Credentials do not establish intended action
Under applicable browser and cookie rules, some cross-site requests can carry target-site session credentials. A service relying only on them may attribute another page’s induced action to the user without an attacker knowing the password.
The effect uses operations exposed by the application and the user’s authority. Unlike XSS it need not inject script into the target page, although the two vulnerabilities can interact.
A defense value must bind to request and session
A synchronizer-token design returns an unpredictable session-bound value in a field or header for server verification. Merely checking an automatically sent cookie or rendering an unverified hidden field does not create that binding.
OAuth callbacks have a related problem. Current guidance binds random state to the user-agent session or uses properly supported, transaction-bound PKCE. Protection follows the binding, not just the presence of a named parameter.
Browser policy and server checks work together
SameSite limits some cross-site cookie delivery; origin checks and request metadata add context. Same-site differs from same-origin, and related subdomains, navigation and compatibility affect policy. One browser attribute is not complete request authorization for every deployment.
Per-request tokens can invalidate submissions from an old page, while per-session values have a different exposure window. Binding and usability both matter. XSS executing inside trusted page context can bypass request defenses and needs its own fix.
References: [1]