What are the risks of storing tokens in cookies?

👨‍💻 Frontend Developer 🟠 May come up 🎚️ Hard
#JavaScript #Browser #JS Basics

Brief Answer

Storing tokens in cookies carries several risks:

  1. XSS attacks — if there’s a vulnerability, attacker can steal cookie 🕵️
  2. CSRF attacks — browser automatically sends cookie, which can be used against user 🎯
  3. Leaks through logs — cookie can end up in server logs and analytics 📊
// ❌ Risks of storing tokens in cookies:
// document.cookie = 'token=abc123'; // Vulnerable to XSS
 
// ✅ Better — use HttpOnly + Secure + SameSite
// Set-Cookie: token=abc123; HttpOnly; Secure; SameSite=Strict

Full Answer

Storing tokens in cookies is like keeping house keys in a jacket pocket. Convenient, but if someone steals the jacket or reaches into the pocket — keys are gone! 🔑

Main Risks

XSS Attacks (Cross-Site Scripting)

// ❌ Problem — if site vulnerable to XSS:
<script>
  // Attacker steals all cookies
  const tokens = document.cookie;
  sendToEvilServer(tokens); // Sends tokens to themselves
</script>
 
// Result: authorization tokens stolen!

CSRF Attacks (Cross-Site Request Forgery)

// ❌ Problem — browser automatically sends cookies:
<img src="https://bank.com/transfer?to=evil&amount=1000" style="display:none">
 
// If user logged in bank, 
// browser automatically sends cookie with token!
// Transfer might succeed without user knowing!

Leaks Through Logs

// ❌ Problem — cookie can end up in logs:
// Request: GET /api/data HTTP/1.1
// Cookie: token=abc123; user=john
 
// Now token in server logs!
// If logs compromised — tokens stolen!

How to Reduce Risks

// ✅ Protection from XSS:
// Set-Cookie: token=abc123; HttpOnly; Secure
// JavaScript DOESN'T see this cookie!
 
// Even with XSS attack, token won't be stolen

SameSite Attribute

// ✅ Protection from CSRF:
// Set-Cookie: token=abc123; HttpOnly; Secure; SameSite=Strict
// Cookie sent only with requests from same site!
 
// CSRF attacks become impossible

Secure Flag

// ✅ HTTPS only:
// Set-Cookie: token=abc123; HttpOnly; Secure
// Cookie sent only over secure connection

Alternatives to Cookies

localStorage/sessionStorage

// ✅ Alternative:
localStorage.setItem('token', 'abc123');
 
// ❌ But also vulnerable to XSS!
// Need additional protection measures

HTTP Headers

// ✅ Modern approach:
// Authorization: Bearer abc123
// Token sent in headers, not cookie
 
// Better controlled and more secure

When You Can Store in Cookies

With Proper Attributes

// ✅ Possible if:
// Set-Cookie: token=abc123; HttpOnly; Secure; SameSite=Strict; Path=/
// - HttpOnly — protection from XSS
// - Secure — HTTPS only  
// - SameSite — protection from CSRF
// - Path — path restriction

For Session Tokens

// ✅ Suitable for:
// - Session tokens
// - Refresh tokens
// - Temporary authorizations

Common Mistakes

Storing Without Protection

// ❌ Bad:
document.cookie = 'authToken=abc123'; // No protection!
 
// ✅ Better:
// Set-Cookie: authToken=abc123; HttpOnly; Secure; SameSite=Strict

Mixing Approaches

// ❌ Bad — part tokens in cookie, part in localStorage
// Creates confusion and additional risks
 
// ✅ Better — unified approach to token storage

Simple Rules

  1. XSS risk — cookies visible in JavaScript (without HttpOnly) 🕵️
  2. CSRF risk — browser automatically sends cookies 🎯
  3. Logs — cookies can end up in server logs 📊
  4. HttpOnly — hides from JavaScript 🛡️
  5. SameSite — protects from CSRF 🚫
  6. Secure — HTTPS only 🔐

Understanding risks of storing tokens in cookies helps create more secure applications! 💪


Want more articles to prepare for interviews? Subscribe to EasyAdvice, bookmark the site and improve yourself every day 💪