136
cross-site request forgery
also CSRF
Another site submits your logged-in user’s cookie. State-changing requests need a token the other site cannot read.
What is cross-site request forgery?
CSRF abuses the browser sending cookies on a request the attacker’s page triggered. Safe methods (GET) must not change state. Unsafe methods need a CSRF token or a same-site cookie plus a custom header the attacker cannot set.
Why does cross-site request forgery matter when vibe coding?
Models use cookie sessions and accept POST from anywhere. A malicious page can change the email. Name the token or SameSite, and do not “fix” it by switching the logout to GET.
How do you do cross-site request forgery?
Cookie session: SameSite=Lax or Strict, plus a CSRF token on POST forms. Authorization headers (not cookies) are not sent cross-site by a form. GET stays safe.
How do you ask a model for cross-site request forgery?
Stop CSRF on cookie-authenticated (actions). GET must not mutate. POST requires a CSRF token or a non-cookie header the attacker cannot forge. Set SameSite on the session cookie.
What goes wrong with cross-site request forgery?
A token that is not checked. The hidden field is decoration. Compare it on the server, tied to the session.