Introduction

Cookies are a convenient mechanism for managing user 인증 state. When a session ID is stored in a cookie, the browser automatically attaches it to outgoing HTTP requests targeting the domain.

However, this automatic attachment 기능 is exploited by Cross-Site Request Forgery (CSRF) attacks.

Although modern browsers default to safer cookie behaviors (such as applying SameSite=Lax automatically), developers must understand CSRF defense patterns to prevent serious 인증 vulnerabilities. This article reviews SameSite cookie attributes and CSRF token verification patterns.

1. How CSRF Attacks Work

A CSRF attack occurs when a malicious website prompts a victim’s browser to execute unwanted actions on a trusted application where the user is currently authenticated.

1. The user logs into a banking application (bank.com), and the 서버 stores a session identifier in a local cookie.
2. While authenticated, the user visits a malicious website (evil.com).
3. The malicious site runs a script that sends a transfer request (POST /transfer) to the banking application (bank.com).
4. Because the request targets bank.com, the browser automatically includes the authenticated session cookie.
5. The bank 서버 processes the request as a legitimate, authenticated session, executing the transaction.

2. Defense 1: SameSite Cookie Attributes

The most effective way to prevent CSRF is by applying the SameSite attribute to session cookies. This 설정 tells the browser whether cookies should be included in requests originating from third-party (cross-site) domains.

The Three Configuration Options

Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Lax

Important Limits of SameSite=Lax

While most modern browsers default to SameSite=Lax, relying on it alone leaves potential security gaps:

1. Incorrect HTTP Method Usage (GET Mutations): If your application performs state changes via GET requests (e.g., GET /delete?id=5), SameSite=Lax will not protect you because Lax allows cookies on cross-site GET link clicks. Always use POST, PUT, or DELETE for state-changing endpoints.
2. Legacy Browser Support: Older mobile WebView environments and legacy 데스크탑 browsers do not recognize the SameSite attribute.

3. Defense 2: The Double Submit Cookie Pattern

To ensure security across all browser environments, applications should use a CSRF Token verification mechanism. A common pattern for stateless Single Page Applications (SPAs) is the Double Submit Cookie pattern.

How it Works

1. When a user authenticates, the 서버 generates a random, cryptographically secure token (the CSRF token) and stores it as a client-side cookie.
2. When the SPA makes a mutation request (POST, PUT, DELETE), JavaScript reads the cookie value and attaches the token to a custom HTTP header (e.g., X-CSRF-Token).
3. The backend 서버 verifies that the token in the request header matches the token in the cookie.

Why This is Secure

While a malicious site (evil.com) can trigger a form submit that automatically includes your application’s cookies, the browser’s Same-Origin Policy (SOP) prevents third-party JavaScript from reading your cookies to attach the token to a custom HTTP header.

Conclusion

Securing your 인증 pipeline against CSRF requires a multi-layered approach:

1. Ensure all session cookies are configured with SameSite=Lax or Strict and include the HttpOnly flag.
2. Never allow state changes to occur via GET requests.
3. Use custom HTTP headers and the Double Submit Cookie pattern to protect mutation endpoints.

Implementing these guidelines will secure your session 인증 and protect users from hijacking attacks.