JWT 저장

(2024년 9월 메모를 기반으로 작성했습니다)

 

쏠거지 프로젝트를 진행하던 당시,

모든 페이지에 접근하는 과정에서 JWT를 확인해야하는데 그러한 경우 토큰을 어디에 저장해야 할지 헷갈렸다.

쿠키에 저장하기에는 "개발자 도구에서 쿠키에 대한 정보를 확인할 수 있기때문에 보안상 문제가 있지 않을까?" 라는 생각을 막연히 가졌었다. 그래서 네이버와 같은 대형 포털사이트에서 어떻게 하는지 로그인해보며 확인해본 결과 그냥 쿠키를 활용하는 것을 확인했다. 이후 쿠키/세션의 개념에 혼동이 와서 정리해본 내용

JWT 저장

쿠키 저장 방식

장점

• HttpOnly 플래그로 XSS 공격 방어 가능
• 요청에 자동 포함되어 편리
• 서버에서 보안 설정 강력하게 제어 가능

단점

• CSRF 공격에 취약 (SameSite 속성으로 완화 가능)
  • SameSite: 키가 cross-site 요청과 함께 전송되어야 하는지를 결정하는 쿠키의 속성.
  • 스프링부트 configuration으로 설정 가능
• 도메인 제한 존재(쿠키를 생성한 도메인에서만 접근 가능)

 

세션 스토리지 저장 방식

장점

• 브라우저 탭별 독립적 저장소
• CSRF 공격에 상대적으로 안전
• 도메인 제한 없음

단점

• XSS 공격에 취약
• JavaScript로 접근 가능하여 보안성 낮음
• 요청에 수동으로 포함 필요

 

그래서 csrf가 뭐지? cors랑 많이 다른가? 

 

CSRF (Cross-Site Request Forgery)

개념

• 사용자가 의도하지 않은 요청을 다른 사이트에서 강제로 실행하게 하는 공격
• 로그인된 사용자의 쿠키를 이용한 공격

방어 방법

1. CSRF 토큰 사용
2. SameSite 쿠키 속성 사용
3. 커스텀 헤더 사용
4. Double Submit Cookie 패턴
5. Origin 검증

 

CORS vs CSRF

CORS (Cross-Origin Resource Sharing)

• 다른 출처의 리소스 공유를 위한 보안 정책
• 브라우저가 다른 출처 리소스 요청 제한
• 서버에서 허용 출처 명시적 설정 필요

주요 차이점

1. 목적

• CORS: 리소스 공유 제어
• CSRF: 위조된 요청 방지

2. 동작 시점

• CORS: 브라우저의 요청 전 검사
• CSRF: 서버의 요청 수신 후 검증

3. 해결 방법

• CORS: Allow-Origin 헤더 설정
• CSRF: 토큰 검증, SameSite 쿠키 등

4. 보안 관점

• CORS: 리소스 접근 제어
• CSRF: 요청의 신뢰성 보장

결론

• 보안이 중요한 경우 HttpOnly 쿠키 사용 권장
• SPA(Single Page Application)의 경우 세션/로컬 스토리지도 많이 사용
• 두 방식 병행하여 장점 활용 가능
• 애플리케이션 요구사항과 보안 수준에 따라 선택