CSRF: Cross-Site Request Forgery tricks a victim's authenticated browser into making an unintended state-changing request. Because cookies are sent automatically, the malicious request appears legitimate to the server.
2 / 5
How does a synchronizer token defend against CSRF?
CSRF token: the server embeds an unpredictable token in forms/headers and validates it on submission. A cross-site attacker cannot read this token (same-origin policy), so forged requests lack it and are rejected.
3 / 5
How does the SameSite cookie attribute help prevent CSRF?
SameSite: setting a cookie to SameSite=Lax or Strict tells the browser not to send it on cross-site requests, neutralizing the automatic-credential behavior CSRF depends on.
4 / 5
Why are pure GET requests that change state especially vulnerable to CSRF?
Unsafe GET: state-changing GETs can be invoked via <img src> or links, which fire automatically. Following HTTP semantics - using POST/PUT/DELETE for mutations - is a baseline defense.
5 / 5
Why is CSRF protection often unnecessary for token-based (Bearer) APIs?
Bearer vs cookies: CSRF relies on credentials the browser attaches automatically (cookies). A token sent in an explicit Authorization header must be added by JavaScript, which a cross-site attacker cannot do, so CSRF does not apply.