쿠키

브라우저의 저장되는 작은 크키의 문자열. (최대 4KB까지 저장할 수 있다)

쿠키의 등장 배경

http의 비연결성, 무상태성 특징으로 인해 현재 요청하는 사용자의 정보를 알 수 없다.
이러한 상황에서 넷스케이프 웹 사이트 방문자가 이미 사이트를 방문했었는 지 확인하기 위해 처음 등장하게 되었다.

특징

1. 주로 서버에서 사용
   서버에서 쿠키를 저장할 수 있기 때문에 주로 서버에서 사용된다.
2. 요청 시 Headers에 전송
   같은 도메인에서 만들어진 쿠키만 전송하게 된다.
3. 만료 기간 지정 가능
   Expires 또는 Max-Age를 통해 만료기간을 지정할 수 있다. 둘 다 존재하는 경우, Expires는 무시된다.

종류

만료 기간에 따라 영구 쿠키와 세션 쿠키로 나뉜다.

영구 쿠키 (Persistent Cookie)

만료 기간이 있다. 만료 기간이 끝난 후 삭제.

세션 쿠키 (Session Cookie)

만료 기간이 없다. 브라우저 종료 시 삭제.

퍼스트파티 쿠키 (First party Cookie)

같은 도메인에서 생성된 쿠키, 서브도메인 경우 포함.

서드파티 쿠키 (Third party Cookie)

다른 도메인에서 생성된 쿠키.
해당 사이트에 다른 도메인의 스크립트가 존재할 때 생성된다.
스크립트 뿐만 아니라, 이미지, 폰트, 아이프레임 등 다른 도메인으로 요청을 해야 하는 경우에 언제든지 생성될 수 있다.

서드파티 쿠키는 주로 광고 목적으로 사용된다. 사용자가 어떤 사이트를 방문했었는지 알 수 있기 때문이다.
하지만 이것은 프라이버시를 침해하고, 개인정보악용에 대한 우려가 있기 때문에 크롬에서는 서드파티 쿠키의 지원을 중단하겠다는 계획을 발표하기도 했다.

문제점

1. 보안적인 문제점: CSRF, XSS 에 노출되어 있다.
   CSRF는 쿠키가 자동으로 전송된다는 특징을 이용해 사이트에 로그인이 되어 있는 사용자에게 악성 스크립트를 실행시켜 비밀번호를 변경하거나 결제 요청을 하는 등 악의적인 요청을 하는 것이다.
   XSS는 Reflected, Stored, DOM-based로 세 가지 종류가 있지만, 원리와 목적은 같다. 악성 스크립트를 실행시켜서, 사용자의 토큰과 같은 민감한 정보를 탈취하는 것이다.

2. 4KB의 부족한 저장 용량

3. http 요청 시 항상 자동으로 모든 쿠키를 전송 - 불필요한 트래픽 증가

Web Storage

HTML5에는 웹의 데이터를 클라이언트에 저장할 수 있는 새로운 자료구조인 Web Storage 스펙이 포함되어 있다.

Key-Value 형식으로 데이터를 저장하고, Key를 기반으로 데이터를 조회하는 패턴.
영구저장소(LocalStorage)와 임시저장소(SessionStorage)를 따로 두어, 데이터의 지속성을 구분할 수 있어 응용 환경에 맞는 선택이 가능하다.

WebStorage는 기존 웹 환경의 쿠키(Cookie)와 매우 유사한 개념이다. 거의 차이가 없지만 몇가지 쿠키의 단점을 극복하는 개선점이 도입됐다. (쿠키는 여전히 유효하고 꽤 적절한 클라이언트 저장도구이다)

Web Storage의 차이점 (cookie와 비교)

1. 쿠키는 매번 서버로 전송된다.
   웹 사이트에서 쿠키를 설정하면 이후 모든 웹 요청은 쿠키정보를 포함하여 서버로 전송된다.
   Web Storage는 저장된 데이터가 클라이언트에 존재할 뿐, 서버로 전송은 이루어 지지 않는다.
   ➡ 이는 네트워크 트래픽 비용을 줄여준다.
   쿠키의 CSRF의 보안 문제와 트래픽 문제 해결.
2. 단순 문자열을 넘어(스크립트) 직렬화를 통해 객체 정보를 저장할 수 있다.
   문자열 기반 데이터 이외에 체계적으로 구조화된 객체를 저장할 수 있다는 것은 개발 편의성을 제공해주는 주요한 장점이 된다. (브라우저의 지원 여부를 확인해봐야 한다.)
3. 최대 5MB의 저장 용량
   쿠키는 개수와 용량에 제한이 있다.
   하나의 사이트에서 저장할 수 있는 최대 쿠키의 개수는 20개고, 최대 쿠키 크기는 4KB로 제한되어 있다.
   그러나 Web Storage에서는 쿠키의 부족한 저장 용량 문제를 해결했다.
   쿠키도 하위키를 이용하면 이러한 제한을 해소할 수 있으나, 대부분 쿠키의 제한으로까지 데이터를 저장할 일은 없다.
4. 영구 데이터 저장이 가능하다.
   쿠키는 만료일자를 지정하게 되어 있어 언젠가 제거된다. 만약 만료일자를 지정하지 않는 경우 세션 쿠키가 된다.
   Web Storage에는 만료 기간의 설정이 없다. 즉, 한 번 저장한 데이터는 영구적으로 존재하는 것이다.

LocalStorage와 SessionStorage

Web Storage는 데이터의 지속성과 관련하여 두 가지 용도의 저장소를 제공한다.

Web Storage는 쿠키와 마찬가지로 사이트의 도메인 단위로 접근이 제한된다. (데이터 보안 측면에서 당연하다)

LocalStorage

저장한 데이터를 명시적으로 지우지 않는 이상, 영구적으로 보관이 가능하다.
도메인마다 별도로 LocalStorage가 생성된다.
Windows 전역 객체의 LocalStorage 라는 컬렉션을 통해 저장과 조회가 이루어진다.

SessionStorage

데이터 지속성과 액세스 범위에 특수한 제한이 존재한다.
Windows 전역 객체의 SessionStorage 라는 컬렉션을 통해 저장과 조회가 이루어진다.

데이터 유지 측면

SessionStorage는 데이터가 지속적으로 보관되지 않는다. 브라우저 기반 세션 쿠키와 그 성질이 비슷한데, 현재 페이지가 브라우징되고 있는 브라우저 컨텍스트 내에서만 데이터가 유지된다.

LocalStorage는 브라우저를 종료해도 데이터는 보관되어 다음번 접속해도 그 데이터를 사용할 수 있다. 반면 SessionStorage는 브라우저가 종료되면 데이터도 같이 지워진다.

즉, 브라우저가 종료되면 SessionStorage 도 삭제된다는 것이다.

데이터 범위 측면

SessionStorage 역시 Web Storage의 기본 보안처럼 도메인 별로 별도로 생성된다. SessionStorage는 같은 사이트의 같은 도메인이라 할지라도 브라우저가 다르면 서로 다른 영역이 된다.
탭 브라우징이나 브라우저를 하나 더 실행했을 때, 이 두 페이지의 SessionStroage는 각각 별개의 영역으로 서로 침범하지 못한다는 의미이다.
이는 도메인만 같으면 전역적으로 공유 가능한 LocalStorage와 구분되는 특징이다.

WebStorage의 보안은 서로 다른 도메인의 침범을 막고 있지만, 클라이언트 즉 사용자를 막고 있지는 않다. 클라이언트는 저장된 값을 임의로 수정이 가능하다. (이것은 쿠키와 동일한 개념)

쿠키에 비해 별다른 보안 취약점을 더 가진 것은 아니다. 따라서 개발자는 사용자에 의한 이러한 임의 변경에 항상 예의 주시하고 방어 코드의 작성을 잊지 말아야 한다.

문제점

1. XSS 에 취약
   자바스크립트로 접근 가능
2. 독립된 스토리지
   브라우저 간 공유가 되지 않기에 다른 브라우저로 접속하거나 데스크탑과 모바일에서 다른 데이터를 볼 수도 있다.
3. 만료 기간 설정 불가
4. 동기적으로 실행
   메인 스레드를 블록킹하게 된다.
   따라서 큰 데이터를 다루는 것을 주의해야 한다.
   용량이 큰 경우에는 IndexedDB를 고려해볼 필요가 있다.

정리

쿠키와 웹 스토리지는 보안 문제가 있기 때문에 민감한 정보는 저장하지 않는 것이 바람직하다.

쿠키는 기간을 설정해야 하거나, 자동으로 서버로 전송되어야 하는 작은 용량의 데이터인 경우 사용할 수 있다.
Ex) n일 동안 보지 않기, 비로그인 장바구니 등

세션 스토리지는 탭을 종료 했을 때 삭제되어도 괜찮은 데이터 인 경우
Ex) 이전 페이지나 이전 스크롤 위치 저장 등

로컬 스토리지는 브라우저를 종료시키고도 유지되어야 하는 경우
Ex) 사용자 설정 저장, 글 임시 저장 등

쿠키 보안 문제 해결 방안

1. XSS : HttpOnly 적용
   HttpOnly를 적용하면 자바스크립트로 쿠키에 접근할 수 없기 때문이다.
2. CSRF : SameSite 적용 / Referer 검증
   SameSite는 같은 도메인의 요청이 아닌 경우, 쿠킬르 전송하지 않는 것. = 악의적인 사이트에서 시작되는 공격이 통하지 않는다.
   • Strick: 모두 허용하지 않음
   • Lax: 안전한 GET 요청만 허용 (a tag)
     Chrome 은 기본적으로 Lax 옵션이 설정되어 있다.

웹 스토리지 보안 문제 해결 방안

1. XSS - innerHTML을 사용하지 않는다.
   사용자의 입력이 자바스크립트 코드로 실행될 수 있는 코드를 작성하지 않는 것. (대표적인 예로 innerHTML이 있다)
   하지만 사용해야 하는 상황이라면 XSS 보안 라이브러리(sanitiza-html, DOMPurify) 를 사용하는 것을 추천.

---

참고

• https://velog.io/@ejchaid/localstorage-sessionstorage-cookie%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90
• https://www.youtube.com/watch?v=-4ZsGy1LOiE