HTTP 쿠키 (Cookie)

조 은길·2022년 3월 17일

HTTP 웹 기본 지식

목록 보기

27/32

이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.

쿠키의 종류

쿠키를 사용할 때는 아래 2개의 헤더를 사용한다.

쿠키 미사용 예제

welcome HTTP/ 라고 접근하면, "안녕하세요 00님"을 기대한다고 가정하자!!

그리고, 로그인을 하면, 로그인에 성공했다는 메시지를 받을 것이다.

그 이후에, 다시 welcome HTTP/를 보내면, 내가 기대하는 것은 "안녕하세요 홍길동님"인데, 다시 "손님"이라고 메세지가 온다. 로그인이 풀린 것이다.

서버 입장에서 welcome HTTP/만 보고, 누구인지 판단할 수 없다. 손님이 보낸 메세지와 다른 게 없기 때문에, "손님"이라고 보낸 것이다.

무상태성

그래서, 이 무상태성의 대안이 무엇인가??

모든 요청에마다 "사용자 정보"를 포함해서 보내면 된다.

그런데, 이 대안은 심각한 문제가 있다.

모든 요청에 사용자 정보를 다 포함해야 한다는 것이다. 이건 보내는 요청량이 늘어나는 문제를 떠나서, 보안상 문제도 발생하고, 개발도 힘들어진다.

모든 요청에 정보를 넘기는 방법의 문제점

그리고 브라우저를 완전히 종료하고 다시 열면... 어떻게 할 것인가??

요즘에는 "웹 스토리지"가 있어서 거기에 저장을 해놓고 다시 넘기면 되기는 한다.

하지만, 이렇게 요청할마다 모든 사용자 정보를 다 넘기는 것은 여전히 힘든 일이다.

이런 문제를 해결하기 위해서, "쿠키"라는 개념이 도입이 된다.

쿠키

웹 브라우저에서 로그인 시에, 사용자 정보를 보내면, 서버에서는 로그인이 성공하면, 해당 정보를 "쿠키 헤더"에 담아서 응답을 한다.

웹 브라우져 내부에는 쿠키 저장소가 있다. 그 저장소에다가 user=홍길동을 저장해둔다.

정리하면, 서버에서 사용자 정보를 담은 "쿠키 해더"를 담아서 응답 메세지를 보내면, 그것을 받은 클라이언트 측의 웹 브라우져는 쿠키 저장소에다가 쿠키를 저장한다.

이제 로그인 이후에, welcome 페이지에 들어간다면, 자동으로 웹 브라우져는 이 서버에 요청을 보낼 때마다 쿠키 저장소에서 해당 쿠키 값을 꺼내서, 요청 메세지에 쿠키를 넣어준다.

서버는 쿠키를 열어보고, 유저가 누구인지 알 수 있다.

이제 더이상 지져분하게 URI에 모든 사용자 정보를 넣어줄 필요가 없다.

쿠키는 지정한 서버에 한해서, 모든 요청 정보에 자동을 포함이 된다.

그런데, 모든 곳에 다 쿠키를 보내면, 보안상 문제가 생기고 여러 잠재적인 문제들이 생길 수 있다.

그래서, 이것을 제약하는 방법들이 있다.

쿠키

다음 쿠키의 예시를 살펴보자

셋 쿠키니까 서버=> 클라이언트로 보내는 응답용 쿠키라는 것을 알 수있다.

세션 방식으로 로그인을 하는지 세션 ID 라는 것이 담겨있다.

쿠키가 만료되는 시간도 보인다.

path는 " 이러한 경로들에 대해서 허용해주겠구나 " 하는 것을 알 수있다.

domain은 " 이러한 도메인들에 대해서 쿠키가 허용이 되는구나 "를 알 수 있다.

Secure는 쿠키에 뭔가 보안 정보를 넣는 구나 하고 이해하면 된다.

쿠키의 주 사용처
- 사용자 로그인 세션 관리 할 때, 진짜 많이 쓴다.
  - 사용자가 로그인을 하면, 서버에서 쿠키에 사용자 정보를 담아서 그대로 브라우져로 내려주는 행위는 보안상 위험하다. 그래서, 로그인이 성공하면, 세션키라는 것을 서버에서 만들어서 그 장소에 사용자 정보를 저장해놓고, 세션 값만 클라이언트에 반환해준다.
  - 클라이언트는 서버에 요청할 때마다 세션ID만을 계속 보내는 것이다.
  - 서버는 세션ID가 있으면, 누군지를 알 수있다.
- 요즘은 "광고 정보를 트래킹"할 때 많이 사용된다.
  - 이 웹 브라우져를 쓰는 사람이 이런 광고들을 주로 보는 구나 하는 것들을 트레킹할 때 쓴다.
쿠키의 정보는 항상 서버에 전송이 되기 때문에, 다음과 같은 단점들이 있다.
- 네트워크 추가 트래픽 유발
  - 아무래도, 쿠키로 인해 몇가지 정보들이 더 넘어가니 트래픽이 커질 수밖에 없다.
- 쿠키에는 최소한의 정보만을 사용해야 한다.
  - 세션 id 값이나 OAuth 방식은 인증 토큰 정보같이 최소한만 넣어야한다.
- "쿠키"처럼 쓰고 싶기는 한데, 이것을 요청할 때마다 보내는 것이 아니고, 클라이언트에 보관하고 싶을 때
  - 즉, 요청할 때마다 쿠키를 보내는 방식이 아닌, 클라이언트에 저장해뒀다가 필요할 때만 클라이언트 웹 브라우저 로직에서 꺼내서 서버에 주는 방식 => 웹 스토리지!!
  - 왜 그런 괴상한 방식을 생각하나??
    - 쿠키는 세팅하면, 서버로 무조건 계속 보내버린다. 그래서 쿠키가 100개 정도 쌓이면, 네트워크 부하가 엄청날 거다. 그래서, 그게 아니고 클라이언트에 저장해놓고 서버에 전송하지는 않고, JS로직에서만 쓸 거면 => "웹 스토리지" 라는 개념을 참고하자!!

참고로, 쿠키이든 웹 스토리지이든 보안에 민감한 정보들은 절대로 저장하면 안 된다.

쿠키의 생명주기

쿠키를 무제한 보관할 수는 없다.

expires
- 쿠키를 만료하기 위해, 날짜를 넣어줄 수 있고, 날짜는 반드시 GMT를 기준으로 넣어줘야 한다.
max-age
- 쿠키를 만료하기 위해, 초단위로 세팅할 수 있다.
- 0이나 음수를 지정하거나, 유효기간이 지나면 쿠키가 삭제될 거다.
max-age 가 expires 보다 우선순위를 갖는다!!
영속 쿠키
- 만료 날짜를 입력하면, 그 날짜까지만 유지되는데..
- 구글 사용할 때, 재부팅해도 로그인 계속 되있는 것이 어느 순간 풀려가지고 다시 로그인해야하는 순간이 있잖아?? 그때 영속 쿠키의 만료 날짜가 되서, 쿠키를 다시 받아야한다고 이해하면 된다.

쿠키의 도메인

내가 지정한 쿠키가 아무 싸이트에나 들어가면, 문제가 생긴다.

그래서, 쿠키는 도메인을 지정할 수가 있다. 여기에는 2가지 방법이 있다.

명시
- 도메인을 명시하게 되면, 명시한 문서 기준 + 서브 도메인을 포함을 해서 다 전송을 한다.
생략
- 도메인을 생략하면, 하위 도메인 (dev.example.org)에서는 쿠키에 접근할 수 없다.

쿠키의 도메인 Q&A

쿠키의 경로

도메인으로 먼저 한 번 필터를 하고, 그 다음에 경로로 추가로 필터를 한다.

그리고 경로를 지정해주면, 해당 경로를 포함한 그 하위 페이지만 쿠키 접근이 가능하다.

일반적으로, path=/ (루트 패스)를 지정한다.

왜냐면, 한 도메인 안에서 보통 쿠키를 다 전송하기를 원한다. 근데, 특별한 경우에는 지정할 수있다.

쿠키의 보안

원래, 자바스크립트에서 쿠키에 접근할 수가 있다. 그런데, HttpOnly를 사용하면, 쿠키에 접근할 수가 없다. 대신에, HTTP 전송에서만 사용할 수가 있다.

SameSite
- 요청하는 도메인과 쿠키에 설정된 도메인이 달라도, 쿠키를 전송할 수 있다.
- 하지만, 이것을 설정해주면, 요청하는 도메인 = 쿠키에 설정된 도메인 때만 쿠키를 전송할 수 있다.
- 그러나, SameSite는 아직 기능 적용된지 몇 년 안되서, 사용시 브라우저에서 어느 정도까지 지원하는지 확인하고 써야한다.