웹브라우저와 웹서버 저장소(Cookie, Storage, Session)

 

 

01. HTTP is a Stateless Protocol

#1. Stateless와 Stateful

💡 Stateless 불연속성

웹서버 입장에서는 매 요청이 어떤 웹브라우저 보낸 것인지 알 수가 없다. 즉, 각 요청이 독립적이며 서버는 이전 요청의 상태를 기억하지 못한다. 서버가 요청의 상태를 유지하지 않으므로 최소한의 자원으로 서버 운영이 가능하다.

 

💡 Stateful 연속성

웹서버가 이전에 요청 받았던 웹브라우저와 현재 요청의 웹브라우저 구별이 가능하다.

즉, 서버가 특정 클라이언트의 상태를 기억할 수 있다면, 어떤 유저의 요청인지 구별 가능하며, 요청마다 개별화된 작업 수행 맞춤형 결과 반환이 가능하다.

 

 

 

02. Stateful HTTP : Cookie & Session

HTTP는 Stateless이지만, 웹서버가 요청을 식별할 수 있도록 Cookie와 Session이 사용된다.

웹 서버는 웹 브라우저의 요청이 어떤 유저에 의해 요청된 것인지 알기 위해 응답 반환 시 요청자 정보를 함께 반환한다.

웹 브라우저는 응답을 받아, 응답 헤더레 붙어있던 요청자 정보를 웹 브라우저 쿠키에 저장하고, 이후 요청부터 웹서버에게 요청자 정보와 함께 전달하여 웹서버는 누구의 요청인지 알 수 있다. 이때 요청자 정보는 어떤 웹브라우저(유저)가 요청했는지 인지 가능한 정보를 말한다.

 

웹 서버가 웹 브라우저에게 최초로 전달할 때는 웹 서버 응답의 헤더 Set-Cookie로 전송한다.

웹 브라우저가 그 이후로 웹 서버에게 전달할 때는 웹 브라우저 요청의 헤더 Cookie로 전송한다.

 

 

#1. Cookie와 Session 차이

요청자 정보를 어디에 저장하는지에 따라 Cookie와 Session으로 구분한다.

💡 Cookie

: 웹 브라우저(클라이언트측)에 저장

: 어떤 값이든 가능하나 일반적으로 노출 방지를 위해 인간이 이해하기 어려운 형태로 저장

 

💡 Session

: 웹 서버(서버측)에 저장

: 웹 브라우저에 저장할 수 없을 정도로 크거나 복합적인 정보, 민감한 정보인 경우를 저장

: 웹 브라우저에는 SESSION.ID라는 식별자만 쿠키에 저장

 

 

 

 

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

웹 서버는 Set-Cookie 헤더를 통해 어떤 데이터를 쿠키로 쓸 것인지, 유효 시간, 보안 설정 등을 관리한다.

 

#1. 쿠키 사용 기준 : Domain + Path

웹브라우저는 요청하는 URL의 도메인과 경로가 쿠키에 설정된 도메인과 경로와 일치할 때만 쿠키를 전송한다.

 

ex) 웹 브라우저 내 다음과 같이 쿠키 리스트가 저장되어 있다.

• 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. 쿠키 유효 시간 : MaxAge / Expires

◼︎ Persistent Cookie(지속 쿠키)

: 쿠키에 유효시간이 명시된 경우 설정된 시간동안 유지

 

◼︎ Session Cookie(세션 쿠키)

: 유효 시간이 명시되지 않은 경우 브라우저 세션이 종료되면 쿠키가 삭제

• 로그인 세션 : 로그인 한 뒤부터 로그아웃까지
• HTTP 세션 : TCP/UDP 연결 후 Request 전송 후 Response 받기까지
• 브라우저 세션 : 하나의 탭/창 열리고 닫기까지

 

 

#3. 쿠키 보안 : HttpOnly, Secure, SameSite

쿠키는 로그인 인증 정보, 광고, 마케팅 데이터 등을 저장할 수 있기 때문에 보안에 취약할 수 있다.

 

◼︎ HttpOnly

자바스크립트로 쿠키에 접근하는 것을 방지하여 XSS 공격을 막는다.

 

◼︎ Secure

HTTPS 채널에서만 쿠키가 전송되도록 하여 MITM 공격을 방지한다.

 

◼︎ SameSite

CSRF 공격 방지하기 위해 쿠키가 동일 사이트에서만 전송되도록 제한한다.

• 퍼스트파티 쿠키 : Site Domain과 Cookie Domain이 일치하는 경우
• 서드파티 쿠키 : Site Domain과 Cookie Domain이 일치하지 않는 경우

 

 

 

#4. Cookie 단점

◼︎ 민감 정보 저장시 보안에 취약

쿠키 정보가 웹브라우저에 저장되어 민감 정보들이 안전하지 않은 상태로 저장되어 있기 때문에 보안에 취약하다.

HttpOnly, Secure, SameSite로 방어가 가능하며, 저장되는 정보들에 대해 웹 서버만의 키로 암호화하고, 볼때마다 복호화할 수 있다.

 

◼︎ 브라우저 간 공유 불가

웹 브라우저 단위의 저장소이기 때문에 지역성 문제가 발생하여 브라우저간 공유가 불가능하다.

웹 브라우저에서 하는 검색과 같은 행위들이 해당 웹브라우저에만 저장된다.

 

◼︎ 네트워크 오버헤드

도메인과 경로가 일치하면 해당 웹서버로 모든 쿠키를 담아서 보내다보니 쿠키로 저장하려는 정보량이 많아질수록 요청 크기가 커진다.

따라서 불필요한 네트워크 오버헤드가 발생하며, 웹서버에게 알려주지 않아도 되는 정보의 경우 웹 스토리지 사용이 권장된다.

 

 

 

 

04. 웹 브라우저 내 저장 : Storage

Storage는 쿠키, 세션과 달리 Stateful HTTP를 위한 기술이 아니다.

HTML5 표준이 등장하기 전에는 쿠키가 웹 브라우저 내 유일한 저장소였으나, HTML5 이후 Storage가 도입되어 더 유연한 데이터 저장이 가능해졌다.

 

#1. Storage와 Cookie 목적 차이

💡 Cookie

: 웹 서버에게 매번 전달한 특정 정보를 저장하는 용도로 사용

: 웹 서버에게 반복적으로 전달해야 하는 작은 정보를 저장

: 만료 시간을 가짐

 

💡 Storage

: 웹 브라우저에서만 사용되는 큰 정보 저장

: 만료 시간 없이 영구적으로 저장

 

 

 

#2. Storage 종류 : 유효 시간 따라

💡 Local Storage

: 웹 브라우저 창이 닫혀도 영구적으로 데이터 저장.

 

💡 Session Storage

: 웹 브라우저 창 닫히면 데이터 삭제

 

 

 

#3. Storage와 Cookie 비교

	Cookie	Storage
저장 가능 용량	4KB	10MB
만료	만료 시간 설정 가능	만료 시간 설정 불가능
범위	지정된 Domain + Path 대해서만 유효	지정된 Domain 내에 모두 유효
보안	웹 서버에게 Non-HTTPS 요청시 노출  - 스크립트 접근 여부 제어 가능	웹 브라우저에서만 접근 가능 - 스크립트 접근 가능
브라우저 간 공유 불가	Session으로 해결 가능	Session으로 해결 가능

 

 

 

 

 

05. 웹 서버 내 저장 : Session

웹 브라우저의 Cookie에는 해당 세션을 식별할 수 있는 SESSION_ID를 저장해야 한다. 웹 브라우저가 종료되면, 세션에 저장된 정보는 시간이 지나면 삭제되어야 한다. 사용되지 않는 정보가 계속 쌓이는 것을 방지하기 위해 캐시와 비슷하게 기존 값을 삭제해야 하며, 저장소가 한정되어 있어 새로운 값이 들어오면 과거의 값들을 삭제하거나, 시간에 따라 기존 값을 제거해야 한다.

 

Session의 대표적인 예는 웹 브라우저에서 쿠키로 SESSION_ID를 받아 해당 요청 유저의 정보를 조회하는 것이다.

API를 수천 번 호출할 때마다 Session을 조회해야 하기 때문에 빠른 응답이 필요하다. 따라서 현업에서는 메모리 기반 DB인 Redis를 많이 사용한다.

 

 

#1. Cookie 단점 -> Session 장점

쿠키의 단점은 Session의 장점이 될 수 있다.

 

쿠키 정보가 웹 브라우저에 저장되기 때문에 민감 정보들이 안전하지 않은 상태로 저장될 수 있다. 또한 쿠키는 웹 브라우저 단위의 저장소이므로, 각 브라우저에서의 활동이 각기 다른 브라우저에 기록되지 않는다. 반면 Session은 정보를 웹 서버에 저장하기 때문에 민감한 정보들이 웹 서버 측에 안전하게 저장된다. Session은 여러 브라우저에서의 활동이 모두 서버에 중앙 기록되어 웹 브라우저 간 공유가 가능하다.

 

쿠키는 Domain + Path가 일치하면 해당 웹 서버로 모든 쿠키를 보내기 때문에 쿠키에 저장된 정보량이 많아질수록 요청 크기도 커진다. 이로 인해 불필요한 네트워크 오버헤드가 발생할 수 있다. 쿠키가 비대해질수록 요청 사이즈도 커지므로, 쿠키를 단순한 저장소로 사용하는 것은 비효율적이다. 웹 서버에 알려줄 필요가 없는 정보는 웹 스토리지를 사용하는 것이 좋다.

반면, Session은 정보를 웹 서버에 저장하기 때문에 얼마나 많은 정보를 저장하더라도 요청 크기에는 영향을 주지 않는다. 단, 매 요청마다 Session 저장소에 저장된 정보를 조회해야 하기 때문에 빠른 DB인 Redis등을 고려해야 한다.