Cookie와 Session: 웹 상태 관리를 위한 필수 개념

• 웹은 기본적으로 상태를 유지하지 않는 Stateless 프로토콜인 HTTP를 기반으로 동작
• 이런 특성 때문에 사용자의 상태를 유지하려면 추가적인 메커니즘이 필요
• 이를 해결하기 위해 사용되는 대표적인 방법이 바로 Cookie(쿠키)와 Session(세션)입니다.

---

클라이언트의 정보를 어디에 저장할까? (Cookie와 Session)

1. 웹 브라우저 내 저장: Cookie

개념과 동작원리

Cookie는 웹 서버가 클라이언트(웹 브라우저)에게 응답할 때 추가적인 헤더 정보를 저장, 이후 클라이언트가 서버에 요청할 때 이 정보를 함께 전달하는 메커니즘.
이를 통해 웹 서버는 같은 클라이언트에서 온 요청임을 식별할 수 있음.

비유: 놀이공원의 재입장 팔찌처럼, 클라이언트를 식별하여 추가 인증 없이도 연속적인 서비스 제공이 가능.

Cookie의 주요 목적

1. 클라이언트 식별 (예: 로그인 인증).
2. 클라이언트 전용 정보 저장 (사용자 환경설정, 장구니 정보, 사이트 방문 정보, 광고 또는 추적 정보 등등)
3. 서버 측에 저장된 정보 식별자 저장 (예: SESSION_ID).

Cookie 속성 (Set-Cookie)

Set-Cookie 헤더를 통해 어떤 데이터를 쿠키로 쓸것인지, 유효시간 및 보안설정을 서버에서 설정하여 제어하는것

1. 도메인 및 경로 (Domain & Path)
   쿠키는 특정된 도메인과 경로(Path)에 따라 전송

• 예) 웹 브라우저 내 저장되어있는 쿠키 리스트

  • 1번 쿠키 : h1 = w1 (Domain: a.com, Path: /)
  • 2번 쿠키 : h2 = w2 (Domain: a.com, Path: /user)
  • 3번 쿠키 : h3 = w3 (Domain: b.com, Path: /hello)
  • 4번 쿠키 : h4 = w4 (Domain: c.com, Path: /world)

• 예) 위 리스트 기반으로 아래 웹 서버에 대한 요청에 따라 전송되는 쿠키 예

  • 웹 브라우저에서 a.com/user/name 호출 시 1번 쿠키 + 2번 쿠키 전송
  • 웹 브라우저에서 a.com/ 호출 시 1번 쿠키 전송
  • 웹 브라우저에서 b.com/hello 호출 시 3번 쿠키 전송
  • 웹 브라우저에서 c.com/ 호출 시 어떤 쿠키도 전송하지 않음

2. Cookie 유효 시간 (MaxAge / Expires)
   명시 되어 있다면 : Persistent Cookie(지속쿠키) -> 유효 기간이 설정된 쿠키로, MaxAge나 Expires 속성을 설정하여 브라우저 종료 후에도 유지됨.
   명시되어 있지 않다면 : Session Cookie(세션쿠키) -> 유효 기간이 설정되지 않은 쿠키로, 브라우저 종료 시 삭제됨.

3. 보안 설정
   HttpOnly: 클라이언트 측 JavaScript를 통해 쿠키에 접근하지 못하도록 설정합니다. (XSS 공격 예방)

   Set-Cookie: sessionId=abc123; HttpOnly;

   Secure: HTTPS 연결에서만 쿠키 전송. (패킷탈취인 MITM 방지)

   Set-Cookie: sessionId=abc123; Secure;

   SameSite: 쿠키의 크로스 사이트 요청 제한을 설정(CSRF 공격 예방)

   Set-Cookie: sessionId=abc123; SameSite=Strict;

   • Strict: 퍼스트파티(동일 사이트) 요청만 허용.
   • Lax: 일부 교차 사이트 요청 허용 (2024년 크롬 기본값).
   • None: 크로스 사이트(모든 교차 사이트) 요청 허용 (Secure 옵션 필수).

Cookie의 한계

• 클라이언트에 저장되므로 노출 가능성이 있으며, 민감한 데이터는 저장하지 않아야 합니다. -> Session으로 해결 가능
• 저장 용량이 브라우저별로 제한적(대부분 4KB 이하) -> Session으로 해결 가능

---

2. 웹 서버 내 저장: Session

개념과 동작 원리

• 서버에서 데이터를 관리하는 방식으로, 클라이언트와의 상태를 유지합니다.

1. 클라이언트가 서버에 접속하면 서버는 고유한 세션 ID를 생헝 후 쿠키를 통해 클라이언트에 전달.
2. 클라이언트는 세션 ID를 쿠키 또는 URL 파라미터를 통해 서버에 전달.
3. 이를 통해 웹 서버는 세션에 저장된 데이터를 기반으로 요청을 처리

특징

• 데이터 저장 위치: 서버에 저장되므로 보안성이 높고, 민감한 정보를 저장하기 적합합니다.
• 수명 관리: 보통 일정 시간이 지나면 자동으로 만료됩니다. 세션 시간은 서버 설정에 따라 조정 가능합니다.
• 확장성의 제약: 서버 메모리를 사용하므로, 사용자가 많아질수록 리소스 부담이 커질 수 있습니다.

Session의 장점

• Session은 정보를 웹 서버측에 저장하다보니

  • 민감 정보들이 웹 서버측에 안정하게 저장되고

  • 웹 브라우저간 공유 가능 : 여러 웹 브라우저를 돌아다니며 행동해도 모두 서버에 중앙 기록된다.

• Session은 정보를 웹 서버측에 저장하는것이기에, 아무리 많은 정보를 저장하더라도 요청을 방해하지 X(쿠키가 방해받지 않는다)

  • 단, 매 요청마다 Session 저장소에 저장된 세션 정보를 조회해야하므로, 빠른 DB 인 Redis 고려할것

Cookie를 활용한 인증의 흐름

1. 사용자가 로그인 요청
   사용자가 ID와 비밀번호를 입력하고, 서버에 로그인 요청을 보냅니다.

   • HTTP 요청: POST /login
   • 요청 데이터: {"username": "user123", "password": "password123"}

2. 서버가 인증 정보를 검증
   서버는 데이터베이스(DB) 등에서 사용자의 인증 정보를 확인하고, 인증에 성공하면 세션 생성 및 세션 ID 발급.

   • 세션 ID는 고유하며, 사용자를 식별하는 키로 사용됨.

3. 서버가 쿠키를 설정
   서버는 세션 ID를 클라이언트로 반환하면서 HTTP 응답 헤더에 Set-Cookie를 포함해 쿠키를 설정합니다.

4. 클라이언트가 쿠키 저장
   브라우저는 서버에서 전달받은 쿠키를 저장하며, 이후 같은 도메인에 요청을 보낼 때 쿠키를 자동으로 포함합니다.

5. 다음 요청에서 쿠키로 인증
   사용자가 인증이 필요한 리소스에 접근할 때 브라우저는 저장된 쿠키를 요청 헤더에 자동으로 추가.
   서버는 요청에 포함된 세션 ID를 확인해 사용자의 인증 상태를 확인합니다.

6. 서버의 인증 처리 및 응답
   서버는 세션 ID를 검증하고, 유효하다면 요청한 리소스를 제공.
   유효하지 않다면, 인증 오류(401 Unauthorized) 응답을 반환