브라우저 저장소의 차이점 (Local Storage, Session Storage, Cookie) - 보안성 비교 / 사용자 인증 토큰은 어디에 저장하는 것이 가장 바람직할까?

브라우저 저장소는 브라우저에서 데이터를 클라이언트 측에 저장하기 위한 기술이다. 이를 통해 웹 애플리케이션은 서버와 상호작용하지 않고도 데이터를 저장하고 관리할 수 있다.

 

브라우저 저장소의 종류는 Web Storage와 Cookie 두 가지로 나뉘고, Web Storage는 Local Storage와 Session Storage로 나눌 수 있다.

 

 

Web Storage

• 웹 데이터를 클라이언트에 저장하기 위한 key-value 형태의 저장소로, Cookie의 단점을 보완하고자 HTML5에 추가된 스펙이다.
• 저장된 데이터는 클라이언트(브라우저)에 존재할 뿐 서버로 전송되지 않는다. 따라서 네트워크 트래픽에 영향을 주지 않는다.
• 쿠키에 비해 용량 제한이 넉넉하다. (서버로 전송되지 않고 그저 클라이언트 측에 데이터를 저장하기 위한 용도이기 때문)
• 만료 기한을 따로 지정하지 않는다.
• 단순 문자열 외에도 객체를 저장할 수 있다.
• 데이터가 변경되면 storage 이벤트에 의해 변경 사항을 감지할 수 있다. (단, 같은 도메인 내에서 다른 브라우저 탭에서 데이터가 변경할 때에만 발생)

 

Local Storage

• 영구적으로, 브라우저를 종료해도 데이터가 유지된다.
• 도메인이 같다면 서로 다른 브라우저 간에도 전역적으로 데이터를 공유할 수 있다.

Session Storage

• 비영구적으로, 브라우저가 종료되면 데이터가 삭제된다.
• 도메인이 같더라도 브라우저가 다르면 각각의 세션 스토리지가 형성되므로 데이터 공유가 되지 않는다.

 

 

Cookie

• 서버와 클라이언트 간의 지속적인 데이터 교환을 하기 위한 key-value 형태의 저장소이다.
• 쿠키 설정 이후의 모든 요청은 쿠키 정보를 포함하여 서버로 전송된다.

🍪 우리가 http 요청을 보낼 때, 요청 자체만으로는 서버에서 이 요청이 어디서 온 것인지 알 수 없다. 이때 쿠키에 정보를 담아서 요청을 하게 되면 서버가 쿠키를 읽어서 이 요청을 누가 보낸 것인지 파악할 수 있게 되는 것이다.

• 쿠키는 서버와의 통신을 목적으로 만들어졌고, 쓸데없는 값이 많을 경우 네트워크 트래픽이 증가하게 되므로 사용 시 유의해야 한다.
• 쿠키 하나당 용량 4KB, 도메인당 20개, 총 개수 300개로 제한이 되어 있다.
• 만료 기한을 지정할 수 있으며, 지정하지 않을 경우 Session Cookie로 취급되어 브라우저가 종료될 때 삭제된다. 지정한 경우에는 브라우저는 닫아도 기한이 지나지 않으면 유지된다.

각각 어떤 경우에 활용하면 좋을까?

Local Storage :

• 브라우저에 영구적으로 저장해야 하는 데이터 (ex. 자동 로그인)
• 클라이언트별 개인화 데이터 (ex. 테마, 언어 등)

Session Storage :

• 임시적으로 저장할 데이터 (ex. 임시 로그인)
• 브라우저 탭/창별로 독립적으로 유지시켜야 하는 데이터

Cookie :

• 서버가 알아야 될 작은 데이터
• 사용자 인증 정보 (ex. 토큰, 세션 ID 등)
• 사용자 행동 및 패턴을 분석하고자 트래킹의 목적으로도 쓰임

 

 

토큰 기반의 사용자 인증 시, 어디에 저장하는 것이 가장 좋을까?

결론 : access token은 memory에, refresh token은 cookie에 저장하는 것이 베스트다.

 

access token은 사용자 정보를 가지고 있기 때문에 기본적으로 브라우저 저장소에 저장하는 것은 보안적으로 안전하지 않다. 따라서 전역 상태 관리 라이브러리 등을 사용하여 메모리로 저장하는 방식이 가장 안전하다. refresh token의 경우, 사용자가 인증된 상태를 유지할 수 있도록 만료된 access token을 재발급 받기 위해 사용되기 때문에 사용자 정보를 직접 담고 있지 않아 브라우저 저장소에 저장해도 괜찮다. 그 중에서도 쿠키에 저장하는 것이 좋은데, 쿠키는 보안이 취약하지만 토큰 암호화, 그리고 HttpOnly, Secure, SameSite, anti-CSRFtokens 등의 플래그를 설정을 통해 위험을 예방할 수 있기 때문이다. 또한, 쿠키는 설정 이후 모든 http 요청 시 헤더에 담겨 서버에 전송되기도 하므로 요청마다 일일히 토큰을 담지 않아도 된다.

 

자세한 내용은 여기에 잘 나와있으니 한 번 쭉 읽어봐도 좋을 것 같다.

 

 

보안 측면에서의 비교

	쿠키 (Cookie)	웹 스토리지 (Local/Session Storage)
XSS 취약성	취약 (HttpOnly 설정 시 완화 가능).	취약 (CSP 및 입력값 검증으로 완화 가능).
도청 위험	취약 (Secure 설정 및 HTTPS 강제화로 완화 가능).	안전 (서버 전송 없음).
CSRF 위험	취약 (SameSite 및 CSRF 토큰으로 방어 가능).	안전 (서버와 동기화되지 않음).
물리적 접근 위험	취약 (암호화 필요).	취약 (암호화 필요).
보안 플래그 지원	지원 (HttpOnly, Secure, SameSite 등 다양한 플래그로 강화 가능).	미지원 (보안 플래그 없음. 보안을 직접 구현해야 함).
민감 데이터 저장	암호화 후 저장 가능. 플래그 설정이 필요한 경우가 많아 복잡도 증가.	저장하지 않는 것이 바람직. 암호화 및 세션 스토리지를 사용하면 민감 데이터 일부 처리 가능.

 

기본적으로 cookie는 매 요청마다 서버에 데이터를 전송하기에 web storage보다 보안에 취약한데, 위와 같이 보완하여 보안을 강화할 수 있다. web storage는 서버에 데이터를 전송하지 않아 도청과 CSRF 공격에는 위험이 없지만 XSS 공격에 취약하고 보안 플래그가 없어 직접 암호화 및 보안을 구현해야 한다.

 

이렇게 저장소별로 보안 측면에서 비교해보고 보완 방법을 알아보았는데, 민감한 정보는 가능한 브라우저 저장소보다는 서버에 안전하게 보관하는 것이 가장 바람직하다는 것을 잊지 말자.

 

---

참고:
브라우저 저장소 차이점 (LocalStorage, SessionStorage, Cookie)
브라우저 저장소의 차이점(Local storage, Session storage, cookie)
LocalStorage vs. Cookies: JWT 토큰을 안전하게 저장하기 위해 알아야할 모든것
JWT는 어디에 저장해야할까? - localStorage vs cookie