8.7 KiB
8.7 KiB
title, source_type, url, archive_url, status, confidence, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | related_branches | related_projects | tags | created | last_reviewed | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OWASP HTML5 Security Cheat Sheet — Web Storage & SPA Token 저장 | official-doc | https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html | raw | high |
|
|
|
2026-05-25 | 2026-05-27 |
OWASP HTML5 Security Cheat Sheet — Web Storage & SPA Token 저장
Layer:
raw/official-docs/— OWASP Foundation 발행. keycloak-patterns P2A (SPA Direct Resource Server) 의 access/refresh token 저장 위치 결정의 1차 근거 — "localStorage 사용 금지" 의 OWASP 직접 인용.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-keycloak-patterns | keycloak-patterns root — SPA 패턴의 token 저장 위치 정책 분기점 |
| raw/branch-notes/feature-keycloak-internal-spa-direct-no-google | P2A SPA Direct — localStorage 금지 + 메모리/cookie 채택 근거 |
| raw/branch-notes/feature-keycloak-internal-spa-direct-google-federation | P2A + Google federation 시점에도 동일한 저장 정책 적용 |
| raw/branch-notes/feature-keycloak-spa-token-storage-tradeoff | localStorage vs memory vs httpOnly cookie 의 trade-off 분석 출처 |
| raw/branch-notes/feature-keycloak-bff-vs-spa-direct | BFF 패턴이 본 OWASP 권고 위반을 근본 회피하는 이유 |
| raw/branch-notes/feature-keycloak-refresh-token-rotation | refresh token 저장 위치 선택 시 본 권고 + rotation 결합 |
| raw/branch-notes/feature-keycloak-vanilla-js-spa-pkce | vanilla JS SPA 구현 시 token 메모리 보관 결정 |
컨텍스트 / 왜 저장했는지
P2A 에서 SPA 가 access_token / refresh_token 을 어디에 두는가가 보안 결정의 핵심. localStorage / sessionStorage 사용이 왜 OWASP 에서 금지되는지 (XSS 단일 결함으로 token 전부 노출) 1차 근거.
출처 / Source
- 원본 URL: https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html
- 아카이브 URL: (미수집)
- 저자 / 조직: OWASP Foundation (Cheat Sheet Series)
- 발행일: rolling docs
- 마지막 확인일: 2026-05-27
핵심 인용 / Key quotes (verbatim)
[§Local Storage] "Do not store session identifiers in local storage as the data is always accessible by JavaScript."
[§Local Storage] "A single Cross Site Scripting can be used to steal all the data in these objects, so again it's recommended not to store sensitive information in local storage."
[§Local Storage] "A single Cross Site Scripting can be used to load malicious data into these objects too, so don't consider objects in these to be trusted."
[§Local Storage] "Use the object sessionStorage instead of localStorage if persistent storage is not needed. sessionStorage object is available only to that window/tab until the window is closed."
[§Local Storage] "There is no way to restrict the visibility of an object to a specific path like with the attribute path of HTTP Cookies, every object is shared within an origin and protected with the Same Origin Policy."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| OWASP-HTML5-C1 | session identifier 를 local storage 에 저장하지 말 것 — data 는 항상 JavaScript 로 접근 가능 | [§Local Storage] "Do not store session identifiers in local storage as the data is always accessible by JavaScript." | official-reference (OWASP cheatsheet) |
SPA 의 session id / token 저장 위치 결정 | "JavaScript 로 접근 가능" 이 모든 JS 코드를 위협으로 본다는 뜻은 아님 — XSS 가 핵심 위협 (다음 claim) |
| OWASP-HTML5-C2 | 단 하나의 XSS 로 local storage 내 모든 data 탈취 가능 — sensitive 정보 보관 비권장 | [§Local Storage] "A single Cross Site Scripting can be used to steal all the data in these objects, so again it's recommended not to store sensitive information in local storage." | official-reference |
XSS 위협 모델 평가 시 | XSS 가 없으면 localStorage 가 안전하다는 뜻은 아님 — 다른 vector (subdomain takeover 등) 별도 |
| OWASP-HTML5-C3 | 단 하나의 XSS 로 local storage 에 malicious data 주입 가능 — storage 내 객체는 trusted 로 간주 금지 | [§Local Storage] "A single Cross Site Scripting can be used to load malicious data into these objects too, so don't consider objects in these to be trusted." | official-reference |
storage 에서 읽은 값의 신뢰도 평가 | data integrity 검증 메커니즘 (signing) 의 효과는 본 인용 범위 밖 |
| OWASP-HTML5-C4 | persistent storage 가 필요 없으면 localStorage 대신 sessionStorage 사용 — sessionStorage 는 해당 window/tab 에만, 창 닫힐 때까지만 유효 | [§Local Storage] "Use the object sessionStorage instead of localStorage if persistent storage is not needed. sessionStorage object is available only to that window/tab until the window is closed." | official-reference |
sessionStorage vs localStorage 선택 | sessionStorage 가 XSS 에 안전하다는 뜻은 아님 — C2 / C3 는 these objects (즉 둘 다) 에 적용 |
| OWASP-HTML5-C5 | localStorage/sessionStorage 객체는 HTTP Cookies 의 path attribute 같은 path-level visibility 제한 불가 — origin 내에서 공유, Same Origin Policy 로만 보호 |
[§Local Storage] "There is no way to restrict the visibility of an object to a specific path like with the attribute path of HTTP Cookies, every object is shared within an origin and protected with the Same Origin Policy." | official-reference |
multi-SPA 또는 path-scoped 권한 분리 시 | cookie 가 항상 더 안전하다는 뜻은 아님 — cookie 는 CSRF risk 별도 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
OWASP-HTML5-C1~C5: localStorage/sessionStorage 의 XSS 노출 위험, 단일 XSS 로 전체 탈취/주입 가능, sessionStorage 권장 조건, origin 내 공유 한계.
- 이 자료가 증명하지 않는 것:
- httpOnly cookie 가 SPA token 저장의 정답이라는 명제 — CSRF risk 별도, SameSite 정책 필요.
- BFF 패턴이 OWASP 공식 권고라는 명제 — BFF 는 OAuth Working Group BCP 및 vendor blog (Curity 등) 출처, 본 cheatsheet 범위 밖.
- access_token 메모리 보관 시 reload 후 silent refresh 가 항상 동작한다는 명제 — Authorization Server 측 session/cookie 정책 의존.
- OAuth token storage 의 전용 가이드 — OAuth 2.0 for Browser-Based Apps (BCP) 별도 문서 필요.
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- P2A 의 refresh_token 보관 위치 — BFF 백엔드 vs httpOnly cookie 선택 결정 (별도 BCP / Curity blog 정독 필요).
- SameSite cookie + CSRF token 결합 설계.
- Keycloak silent refresh (
prompt=none+ iframe) 가 P2A SPA 의 reload 후 token 재획득 시 동작하는지 시연.
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. P2A 해석.
- 정책 함의 (P2A 적용):
access_token: 메모리 (JS 변수). reload 시 silent refresh 또는 재로그인.refresh_token: 이상적으로는 BFF 백엔드 보관. SPA Direct 에서는 secure + httpOnly + SameSite cookie 차선.- localStorage / sessionStorage 사용 금지.
- httpOnly cookie 의 한계: CSRF 위험 → SameSite=Strict + CSRF token 결합.
- BFF 패턴은 이 문제의 근본 해결책 — 토큰 자체가 브라우저에 닿지 않음. Curity 문서 참조 (raw/company-tech-blogs/curity-bff-pattern-spa).
- 본 cheatsheet 는 일반 HTML5 storage 관점. OAuth 토큰 전용 가이드는 OAuth Working Group 의 "OAuth 2.0 for Browser-Based Apps (BCP)" 별도 문서로 보충 필요 (본 branch 범위 외).
Related / 관련
- 같은 주제 다른 official-doc:
- raw/official-docs/oauth-v2-1-draft-ietf (OAuth 2.1 draft — browser-based apps 권고 일부 포함)
- raw/official-docs/oauth2-pkce-rfc-7636 (PKCE — SPA 의 token endpoint 보호)
- 인용하는 branch:
- 인용하는 wiki: (미작성)