How do you securely handle authentication in SSR? What are the risks of passing tokens via cookies vs headers?

Question

Accepted Answer

Authentication in Server-Side Rendering (SSR) presents unique challenges because the server needs access to authentication state during the initial page render, before any client-side JavaScript runs. The core requirement is that authentication credentials must be automatically included in HTTP requests made by the server. This fundamental constraint explains why cookie-based authentication dominates SSR architectures: cookies are automatically sent with every HTTP request by the browser, making them accessible in getServerSideProps, middleware, and server components. Header-based authentication (like Authorization: Bearer) fails in SSR because these headers must be manually attached by client-side JavaScript, which hasn't executed during server rendering. Automatic transmission: Cookies are included in every HTTP request automatically, making them available during server-side rendering without any client-side code execution. Middleware compatibility: Cookies can be read in Next.js middleware, enabling authentication checks before pages render and allowing early redirects for unauthenticated users. Server Components access: With the App Router, cookies() function provides direct access to cookie values in Server Components, enabling data fetching based on user identity. Unified auth model: Cookies work consistently across all Next.js environments: Server Components, Route Handlers, Middleware, API Routes, and SSR. Header-based authentication breaks SSR because the server cannot access tokens stored in localStorage or sessionStorage during the initial render. When a user visits a protected route like /dashboard directly, the sequence of events reveals the problem: the server renders the page without authentication context, sends unauthenticated HTML, client JavaScript loads, reads the token from storage, and finally fetches protected data—causing UI flickering, extra network requests, and a poor user experience. This is why header-based auth with localStorage is fundamentally incompatible with SSR requirements. // Backend API (Express example) - Set HTTP-only cookie on login
import jwt from 'jsonwebtoken';

app.post('/login', async (req, res) => {
  // Authenticate user...
  const token = jwt.sign(
    { userId: user._id },
    process.env.JWT_SECRET,
    { expiresIn: '7d' }
  );
  
  // Set secure HTTP-only cookie
  res.cookie('authToken', token, {
    httpOnly: true,           // Prevents XSS attacks - JavaScript cannot access
    secure: process.env.NODE_ENV === 'production', // HTTPS only
    sameSite: 'strict',        // Prevents CSRF attacks
    maxAge: 7 * 24 * 60 * 60 * 1000 // 7 days
  });
  
  res.json({ message: 'Login successful' });
});

// Next.js Pages Router - Read cookie in getServerSideProps
export async function getServerSideProps({ req }) {
  const token = req.cookies.authToken;
  
  if (!token) {
    return {
      redirect: { destination: '/login', permanent: false }
    };
  }
  
  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    const userData = await fetchUserData(decoded.userId);
    
    return { props: { user: userData } };
  } catch (error) {
    // Token invalid or expired
    return {
      redirect: { destination: '/login', permanent: false }
    };
  }
}

// Next.js App Router - Read cookie in Server Component
import { cookies } from 'next/headers';
import { verify } from 'jsonwebtoken';

export default async function DashboardPage() {
  const cookieStore = await cookies();
  const token = cookieStore.get('authToken')?.value;
  
  if (!token) {
    redirect('/login');
  }
  
  try {
    const decoded = verify(token, process.env.JWT_SECRET);
    const userData = await fetchUserData(decoded.userId);
    
    return <Dashboard user={userData} />;
  } catch {
    redirect('/login');
  }
} XSS vulnerability: Tokens in localStorage/sessionStorage are accessible to any JavaScript running on your site, making them stealable via XSS attacks. HTTP-only cookies cannot be read by JavaScript, eliminating this risk. CSRF protection: Cookies require CSRF protection via SameSite=strict/lax attributes or CSRF tokens. Header-based tokens are naturally immune to CSRF because browsers don't automatically include custom headers in cross-origin requests. SSR compatibility: Cookies work automatically with SSR. Headers fail during server rendering because tokens must be manually attached by client JavaScript. Token storage security: localStorage is vulnerable to XSS and can be accessed by third-party scripts, browser extensions, and compromised dependencies. HTTP-only cookies remain protected even if malicious scripts execute. Request forgery risk: GET requests with cookies can expose user data via CSRF if not properly protected. The official stance is that SSR is secure when GET requests never trigger state-changing operations and CORS headers are correctly configured. Storing authentication tokens in localStorage creates a severe security risk because any XSS vulnerability—

How do you securely handle authentication in SSR? What are the risks of passing tokens via cookies vs headers?

Securely handle SSR authentication by storing tokens in HTTP-only cookies for automatic server-side transmission, while avoiding header-based tokens that break SSR and localStorage that exposes XSS vulnerabilities

How do you securely handle authentication in SSR? What are the risks of passing tokens via cookies vs headers?

Securely handle SSR authentication by storing tokens in HTTP-only cookies for automatic server-side transmission, while avoiding header-based tokens that break SSR and localStorage that exposes XSS vulnerabilities

Scenario Questions

Follow-up Questions