When You Need CSRF Protection
CSRF in One Paragraph
Cross-Site Request Forgery: a malicious page makes your browser send a request to ShopEase. If ShopEase identifies you by a cookie, the browser attaches it automatically, and the request runs as you (for example "change delivery address"). The attacker cannot read the response, but the damage is done. The basic level explains the attack; here we decide what to do.
| How the API identifies the user | Sent automatically by the browser? | CSRF protection |
|---|---|---|
Authorization: Bearer header (JS adds it) | No | Not needed: csrf.disable() is fine |
Session cookie (JSESSIONID) | Yes | Needed: keep CSRF on |
Refresh token cookie (/api/auth/refresh) | Yes | Needed for those endpoints (SameSite + CSRF token) |
| Access token stored in a cookie | Yes | Needed everywhere |
SameSite Cookies
SameSite=Strict or Lax tells the browser not to send the cookie on requests started by other sites. It blocks most CSRF on modern browsers. Use it on every auth cookie, but treat it as one layer, not the only one: older browsers and some sub-domain setups can bypass it.
Tip: A "site" is the registrable domain: shopease.in, api.shopease.in and admin.shopease.in are the same site but different origins. So SameSite does not protect you from a compromised sub-domain; a CSRF token does.