Cookie

• 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
• 그럼 왜 전달할까? -> HTTP는 기본적으로 무상태 프로토콜이기 때문이다.

Stateless

• 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.
• 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못 한다.
• 클라이언트와 서버는 서로 상태를 유지하지 않는다.

• 그럼 서버는 Stateless protocol에서 어떻게 사용자가 누구인지 알 수 있을까?

1. 대안 1: 모든 요청에 사용자 정보를 포함한다.
   • 개발자가 모든 요청에서 사용자 정보를 추가하고 이를 처리해야하는 로직을 작성해야한다.
   • 보안성이 심각하다.
   • 브라우저를 종료하고 나면 웹 스토리지를 사용하면 되긴 하지만 무튼 이를 처리하는 로직을 개발해야한다.
2. 대안 2: 그냥 쿠키를 쓴다.
   
   • Set-Cookie: 서버에서 클라이언트로 set-cookie 헤더를 만들어서 쿠키를 전달(응답)한다.
   • 웹브라우저는 쿠키 저장소가 있는데 거따가 저장해둔다.
   • 그럼이제 자동으로 웹브라우저는 서버에 요청을 보낼 때마다 쿠키를 뒤져서 해당 값을 찾아 쿠키 헤더를 만들어서 서버에 보낸다.
   • 그래서 쿠키는 모든 req에 자동으로 넣어서 보낸다.

Set-Cookie

• 쿠키 주 사용처

  • 사용자 로그인 세션 관리 (서버에서는 사용자 정보대신 세션 키(id)를 만들어서 DB에 저장해뒀다가 요청하면 반환해준다.)
  • 광저 정보 트래킹

• 쿠키 정보는 항상 서버에 전송됨!

  • 네트워크 트래픽 추가 유발, 그래서 최소한의 정보만 사용해야한다. (세션 id, OAuth라면 인증 토큰)
  • 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지(local, session storage)에 저장

• 이때 보안에 민감한 데이터는 쿠키든, 웹 스토리지든 모두 저장하면 안됨(주민번호, 신용카드 번호 등등)

Cookie life-cycle

• Set-Cooke: expires=Sat, {GMT 기준 날짜}|
  • 만료일이 되면 쿠키 삭제
• Set-Cooke: max-age=3600
  • 3600초 후 삭제
  • 0이나 음수를 지정하면 쿠키 삭제
• 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
• 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키-도메인

• 위 사진 중간에 Domain=.inflearn.com이라고 적혀있다.

• 명시: 명시한 문서 기준 도메인+서브도메인 포함

  • Domain=example.org를 지정해서 쿠키 생성
    • axample.org는 물론이고 dev.example.org도 쿠키 접근

• 생략: 현재 문서 기준 도메인만 적용

  • example.org에서 쿠키를 생성하고 domain 지정을 생략
    • example.org에서만 쿠키 접근하지만 dev.example.org는 쿠키 미접근

쿠키-경로

• 위 사진에 Path=/를 볼 수 있는데
• 이 경로를 포함한 하위 경로 페이지만 쿠키 접근할 수 있다.
• 일반적으로 path=/ 루트패스로 지정한다.

• path=/home 을 지정하였다면
  • /home => ok
  • /home/lv1/lv2 => ok
  • /hello => no!

쿠키-보안

• Secure

  • 쿠키는 기본적으로 http, https를 구분하지 않지만
  • Secure를 적용하면 https인 경우에만 전송한다.

• HttpOnly

  • XSS 공격을 방지하기위해 작성한다.
  • JS에서는 접근이 불가능하다.
  • HTTP 전송에만 사용한다.

• SameSite

  • XSRF 공격 방지
  • 요청 도메인과 쿠키에서 설정된 도메인이 같은 경우에만 쿠키를 전송한다.
  • 브라우저에서 지원하는지 확인하고 사용해야함.