CSRF Cross-Site Request Forgery – Java Backend Security
Fast recall
Quick revision
Core answer
SameSite tells a browser when a cookie is eligible to accompany a cross-site request. Strict omits it on cross-site requests. Lax allows it on some top-level navigations that use a safe method, while blocking common cross-site POST and embedded-request cases. None permits cross-site use and requires Secure, although browser privacy settings may still block it. SameSite reduces CSRF exposure but should be treated as defense in depth rather than the only check for sensitive actions.Interview-ready guide
Interview answer
The SameSite attribute tells the browser when a cookie may accompany a request that starts on another site. It helps against CSRF because a forged request is less useful when the browser withholds the authentication cookie.
With Strict, the cookie is omitted on cross-site requests. The cookie is not deleted, so the user is not literally logged out; the first inbound request may simply look unauthenticated. Lax keeps normal top-level navigation working for safe methods but normally blocks the cookie on cross-site POSTs and embedded requests. None permits cross-site use and requires Secure, although browser privacy settings may still prevent third-party cookies.
SameSite is a useful browser-side barrier, but it is defense in depth. Sensitive writes should still use a CSRF token or an equivalent request-intent check, and GET must remain read-only. The application should set SameSite explicitly rather than depend on a browser's default behavior.
CSRF Cross-Site Request Forgery – Java Backend Security
Direct Answer
SameSite tells a browser when a cookie is eligible to accompany a cross-site request. Strict omits it on cross-site requests. Lax allows it on some top-level navigations that use a safe method, while blocking common cross-site POST and embedded-request cases. None permits cross-site use and requires Secure, although browser privacy settings may still block it. SameSite reduces CSRF exposure but should be treated as defense in depth rather than the only check for sensitive actions.
Common Mistakes & Pitfalls
- Treating SameSite as the only CSRF defense: keep a token or equivalent check for sensitive unsafe requests.
- Relying on an omitted attribute: browser defaults and compatibility behavior can vary; set the intended value explicitly.
- Using
NonewithoutSecure: modern browsers reject that combination. - Saying Strict logs the user out: the cookie remains stored; it is simply omitted on the cross-site request.
- Confusing SameSite with HttpOnly: HttpOnly blocks JavaScript from reading the cookie, but injected script can still send authenticated requests.
Check your understanding
Answer these without looking back at the article.
- Why is SameSite=Lax the modern default and what does it still allow?
- Is SameSite enough on its own, or do you still need CSRF tokens?
- Why does SameSite=None require the Secure attribute?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.