localStorage, sessionStorage, cookie (feat. 토큰에 대한 고찰)

• localStorage
  • 비휘발성 (직접 삭제하지 않는한 영구적으로 존재)
    
    • 브라우저를 닫아도 데이터가 유지
    • 사용자가 직접 삭제하거나 코드로 제거하기 전까지 계속 저장
  • 용량:
    • 5MB ~ 10MB의 저장 공간 (브라우저에 따라 다름)
  • 데이터 형식:
    • key-value 쌍으로 데이터를 저장
    • 모든 값은 문자열로 저장. 객체나 배열을 저장할 때는 JSON.stringify()를 사용해 직렬화
  • 도메인 별 저장:
    • 다른 도메인에서는 접근할 수 없음
  • setItem(), getItem(), removeItem(), clear() 등등의 메서드
  • 보안:
    • 클라이언트 측에 저장어서 유저들 또한 직접 접근 가능. 
    • HTTPS를 사용해도 XSS 공격에 취약할 수 있습니다.
• sessionStorage:
  • 세션 기반 지속성:
    • 데이터는 브라우저 탭 또는 창이 열려있는 동안에만 유지
    • 탭이나 창을 닫으면 데이터가 자동으로 삭제
  •  용량:
    • 일반적으로 5MB에서 10MB의 저장 공간을 제공
  • 데이터 형식:
    • 키-값 쌍으로 데이터를 저장
      • 모든 값은 문자열로 저장되며, 객체나 배열은 JSON.stringify()로 직렬화
    1.  
  • 도메인 및 탭/창 제한:
    • 같은 출처(origin)에서만 접근 가능합니다.
    • 각 탭/창마다 독립적인 sessionStorage가 생성됩니다.
  • setItem(), getItem(), removeItem(), clear() 등
  • 보안
    • 클라이언트 측에 저장되므로 민감한 정보 저장은 피해야 합니다.
    • 세션 단위로 데이터가 제한되어 LocalStorage보다는 상대적으로 안전할 수 있습니다.
  • storage 이벤트가 발생하지 않음 (같은 세션 내에서만 데이터가 유지되기 때문).
  • 로컬 스토리지와의 차이점
    • 데이터의 지속 기간이 세션으로 제한됩니다.
    • 각 탭/창마다 독립적인 저장소를 가집니다.
• cookie

쿠키(Cookie)는 웹 브라우저에 저장되는 작은 데이터 조각

웹 서버가 사용자의 웹 브라우저에 전송하며, 브라우저는 이를 저장했다가 동일한 서버로 다음 요청 시 함께 전송 

1. 크기 제한:
   • 일반적으로 4KB 이하의 작은 텍스트 파일
2. 만료 기간:
   • 세션 쿠키: 브라우저 종료 시 삭제
   • 영속 쿠키: 지정된 만료 날짜까지 유지. 만료시 자동 삭제
3. 서버 전송:
   • 매 HTTP 요청마다 서버로 자동 전송
4. 도메인 제한:
   • 특정 도메인에 대해서만 유효
5. 보안:
   • Secure 플래그: HTTPS 연결에서만 전송
   • HttpOnly 플래그: JavaScript에서 접근을 방지 -> 토큰 관리시 유용
   • SameSite 속성: CSRF 공격 방지에 도움
6. 사용 목적:
   • 세션 관리: 로그인 상태, 장바구니 등 유지
   • 개인화: 사용자 선호 설정 저장
   • 트래킹: 사용자 행동 분석
7. 접근 방식:
   • 서버 측: HTTP 헤더를 통해 설정 및 읽기
   • 클라이언트 측: JavaScript의 document.cookie로 접근
8. 제한 사항:
   • 브라우저별 쿠키 수 제한 (일반적으로 도메인당 50개)
   • 제3자 쿠키에 대한 브라우저 정책 변화
9. 프라이버시 문제:
   • 사용자 추적에 사용될 수 있어 프라이버시 우려가 있습니다.
10. localStorage/sessionStorage와의 차이:
    • 서버로 자동 전송됨
    • 용량이 더 작음
    • 만료 기간 설정 가능
11. 법적 규제:
    • 많은 국가에서 쿠키 사용에 대한 사용자 동의를 요구합니다 (예: GDPR).

 

 

localstorage에서 데이터에 대한 만료시간을 지정하고 싶다면 그것에 대한 데이터를 로컬에 저장해주면 된다.

이후 접근시 만료 체크해주고.. 쿠키 같은 경우에는 만료 시간을 옵션으로 지정해주면 자동으로 삭제된다.

액세스 토큰(만료시간이 있는)과 같이 로그인 유지를 위해 필요한  데이터를 로컬에 만료 데이터 값을 추가하여 관리할지 쿠키에 옵션으로 줘서 자동으로 삭제할지에 대한 고민으로는 

1. 로컬 스토리지 (localStorage) 사용:

장점:

• 용량이 더 크다 (일반적으로 5-10MB).
• JavaScript에서 쉽게 접근 가능.
• 서버로 자동 전송되지 않아 네트워크 부하 감소.

단점:

• XSS(Cross-Site Scripting) 공격에 취약할 수 있음.
• JavaScript로 접근 가능하므로 보안상 위험할 수 있음.

1. 쿠키 (Cookie) 사용:

장점:

• HttpOnly 플래그를 사용하여 JavaScript 접근을 방지할 수 있음.
• Secure 플래그로 HTTPS 연결에서만 전송 가능.
• SameSite 속성으로 CSRF 공격 방지 가능.

단점:

• 용량 제한 (일반적으로 4KB).
• 모든 HTTP 요청에 자동으로 포함되어 네트워크 부하 증가.

권장사항: 보안이 중요한 액세스 토큰의 경우, 일반적으로 쿠키를 사용하는 것이 더 안전. 

1. HttpOnly 플래그 사용: JavaScript에서 쿠키 접근 방지
2. Secure 플래그 사용: HTTPS 연결에서만 전송
3. SameSite=Strict 또는 SameSite=Lax 설정: CSRF 공격 방지
4. 짧은 만료 시간 설정: 토큰의 유효 기간을 제한

추가 고려사항:

• 서버 측에서 토큰 검증을 철저히 수행.
• 필요한 경우 refresh 토큰을 사용하여 액세스 토큰의 수명을 짧게 유지.
• 민감한 작업 수행 시 추가 인증 요구.

결론: 보안이 최우선이라면 적절히 설정된 쿠키 사용을 권장. 그러나 애플리케이션의 특성, 사용자 경험, 개발 편의성 등을 종합적으로 고려하여 결정해야 함. 이전까지는 서버로부터 리프레쉬 토큰과 액세스 토큰 둘다 받아온다면 리프레쉬는 서버에서 쿠키에 HttpOnly 설정과 함께 보내줬고 액세스는 응답 데이터에서 추출해서 로컬이나 메모리에 저장했다 .(쿠키 용량+리프레쉬가 CSRF 공격을 당하더라도 그걸로 할 수 있는건 액세스 재발급 뿐이니까 액세스에 대한 방어 체계만 보안상 신경쓰면 돼서 + RTR 기법에 의거하여 한번 액세스를 발급 받은 리프레쉬는 폐기 처리)

• cf) 쿠키에 액세스 토큰을 담았을 때 CSRF 공격에 취약한 것은 쿠키에 담긴 액세스를 탈취해오기 때문이 아니라/ 통신시 쿠키가 자동으로 서버로 같이 넘어가서 이것을 통해 서버의 민감한 정보를 수정할 수 있기 때문에 위험한거다. -> 쿠키에 저장 된 데이터로 서버가 조작되는 것을 방지하기 할려면 외부 서비스에서 우리 서비스의 데이터를 변경하는 요청을 보내지 못하게 만든다라는 특징을 사용하면 된다. -> SameSite

https://curity.medium.com/best-practices-for-storing-access-tokens-in-the-browser-6b3d515d9814

 

• 아래는V0 에게 물어본 결과