auditing-csrf-and-unsafe-state-changeslisted

# Auditing CSRF and unsafe state changes: when the victim's cookies do the attacker's work A browser attaches a site's cookies to every request to that site, whoever caused the request. So when a state-changing endpoint authorizes an action on the session cookie alone, an attacker's page can submit a form or fire a request to that endpoint, the victim's browser attaches the session, and the change happens as the victim without them ever intending it. The defense is proof that the request originated from the app's own pages and not a foreign one: an unpredictable token bound to the session that an attacker cannot guess or read cross-origin, or a cookie policy that withholds the cookie on cross-site requests. The bug is a state change that trusts the cookie and asks for nothing else. You find it by listing every action that mutates state and checking what, beyond the cookie, each one requires. ## When to use - An endpoint changes data, settings, access, or funds and is authorized by a session cookie. - Forms or actions rely on a token, and you need to confirm it is present, validated, and session-bound. - The app relies on same-site cookie behavior, custom headers, or content-type as its only cross-site guard. ## Scope check Test cross-site request forgery only against applications you own or are authorized to assess, using test accounts and a benign state change you can observe and reverse, never triggering a real irreversible action on another user. A confirmed case perf