편리한 Cookie

쿠키는 브라우저가 요청마다 자동으로 서버에 포함한다

예를 들어

Set-Cookie: token=abc123

를 서버가 보내면 브라우저가 저장한다.

그리고 이후 요청마다

Cookie: token=abc123

를 자동으로 포함한다. 개발자가 직접 넣지 않아도 된다.

CSRF 조심

로그인 구현할 때도

쿠키 저장
→ 자동 인증 유지

라서 굉장히 편하다.

하지만 “자동으로 전송된다”는 건 공격자 입장에서도 편한 것이기 때문에 항상 CSRF 조심!

Cookie는 서버와 “함께 쓰는 저장소” 느낌

쿠키는 localStorage.setItem() 처럼 프론트가 마음대로 쓰는 저장소라기보다,

서버가 브라우저에게 “이 값을 저장하고, 앞으로 이런 규칙으로 보내라”고 지시하는 인증 장치에 가깝다.

Set-Cookie: token=abc; HttpOnly; Secure; SameSite=Lax

이 한 줄 안에 보안 정책이 들어 있다.

1. Set-Cookie

로그인 성공 후 서버가 응답 헤더로 보낸다.

HTTP/1.1 200 OK
Set-Cookie: token=abc123; HttpOnly; Secure; SameSite=Lax

브라우저는 이걸 보고 쿠키 저장소에 저장한다.

이후 같은 조건의 요청을 보낼 때 자동으로 붙인다.

GET /mypage HTTP/1.1
Cookie: token=abc123

즉 프론트가 매번 직접

headers: {
  Authorization: `Bearer ${token}`
}

이렇게 넣지 않아도 된다.

2. HttpOnly: JavaScript 접근 차단

Set-Cookie: token=abc; HttpOnly

이 옵션이 있으면 JS에서 읽을 수 없다.

document.cookie

로 접근해도 token이 보이지 않는다.

이게 중요한 이유는 XSS 때문이다.

만약 토큰을 localStorage에 저장하면 XSS 발생 시

localStorage.getItem("token")

으로 바로 탈취될 수 있다.

하지만 HttpOnly Cookie JS가 읽을 수 없어서 토큰 탈취 위험을 줄인다.

다만 중요한 점

HttpOnly는 “탈취”를 줄여주는 것이지, XSS 자체를 완전히 막는 것은 아니다.

XSS 코드가 실행되면 쿠키를 읽지는 못해도, 사용자의 브라우저에서 인증된 요청을 보낼 수는 있다.

3. Secure: HTTPS에서만 전송

Set-Cookie: token=abc; Secure

이 옵션이 있으면 쿠키는 HTTPS 요청에서만 전송된다.

즉 이런 요청에는 쿠키가 붙는다.

https://example.com

하지만 이런 요청에는 붙지 않는다.

http://example.com

HTTP는 암호화되지 않기 때문에 네트워크 중간에서 쿠키가 노출될 수 있다.

그래서 인증 쿠키에는 거의 항상 Secure 를 붙여야 한다.

4. SameSite: 다른 사이트 요청에 쿠키를 보낼지 결정

Set-Cookie: token=abc; SameSite=Lax

이 옵션은 CSRF와 직접 관련 있다.

쿠키는 기본적으로 브라우저가 자동 전송한다.
이 자동 전송을 공격자가 악용하는 게 CSRF다.

예를 들어 사용자가 bank.com에 로그인한 상태에서 공격 사이트에 들어갔다고 하자.

공격 사이트가 이런 요청을 만들 수 있다.

<img src="https://bank.com/transfer?amount=1000000" />

브라우저가 bank.com쿠키를 자동으로 보내면 서버는 정상 사용자 요청처럼 착각할 수 있다.

samesite는 이걸 제한한다.

SameSite 옵션 3가지

SameSite=Strict

가장 강하다.

다른 사이트에서 출발한 요청에는 쿠키를 거의 보내지 않는다.

Set-Cookie: token=abc; SameSite=Strict

보안은 강하지만 UX가 불편할 수 있다.

예를 들어 외부 링크를 눌러 내 사이트에 들어왔는데 로그인 상태가 바로 반영되지 않는 경우가 생길 수 있다.

SameSite=Lax

가장 많이 쓰는 기본 선택지다.

Set-Cookie: token=abc; SameSite=Lax

대체로 다른 사이트의 위험한 요청에는 쿠키를 안 보내고,
사용자가 링크를 클릭해서 들어오는 일반 이동에는 쿠키를 보낸다.

즉 보안과 UX의 균형이다.

SameSite=None

다른 사이트 요청에도 쿠키를 보낸다.

Set-Cookie: token=abc; SameSite=None; Secure

이건 주로 다음 상황에서 필요하다.

다른 도메인 프론트와 API 서버 연동
임베드 iframe
외부 서비스 연동

단, SameSite=None 반드시 Secure 와 같이 써야 한다.

정리

인증 토큰을 저장할 때

Set-Cookie: accessToken=...;
HttpOnly;
Secure;
SameSite=Lax;
Path=/;
Max-Age=900

이런 식으로 두면 좋다.

HttpOnly → JS 탈취 방지
Secure → HTTPS에서만 전송
SameSite=Lax → CSRF 위험 감소
Max-Age → 토큰 수명 제한
Path=/ → 쿠키 적용 경로 지정

핵심은 이거다.

쿠키는 “값을 저장하는 기능”보다 “브라우저에게 보안 규칙을 강제시키는 기능”이 더 중요하다.

세션 쿠키와 영구 쿠키

세션 쿠키

만료 시간이 없다. 즉 브라우저 종료 시 삭제된다.

보통 메모리 기반이다.

Set-Cookie: sessionId=abc

영구 쿠키

만료 시간이 지정된다.

Set-Cookie: token=abc;
Expires=...

이 경우 디스크에 저장된다.

즉 브라우저를 꺼도 유지된다.

쿠키의 Domain 범위

쿠키는 Domain 설정에 따라 범위가 달라진다.

Domain=.example.com

이렇게 설정하면:

같은 서브도메인에서도 공유 가능하다.

쉽지만 위험한 LocalStorage

localStorage.setItem('token', jwt);

엄청 단순하다.

서버 자동 전송 없음
JS로 자유롭게 사용 가능
용량 큼
브라우저 꺼도 유지

쿠키보다 더 사용하기에도 쉽다.

LocalStorage, XSS의 위험

가장 큰 문제는 JavaScript에서 접근 가능 하다는 점이다. 즉 XSS가 발생하면

localStorage.getItem('token')

로 토큰 탈취 가능. 이 순간 LocalStorage가 단순 저장소가 아니라

“브라우저 내부 JS 실행 환경과 직접 연결”

되어 있다는 걸 느꼈다.

SessionStorage

처음엔 LocalStorage랑 거의 같은 줄 알았다. 근데 다르다. 가장큰 차이는 탭 단위 저장소 라는 점이다.

SessionStorage는 탭마다 분리된다

같은 사이트라도

새 탭
새 창

이면 서로 공유되지 않는다.

즉

Origin + Tab

기준으로 분리된다.

왜 SessionStorage는 메모리 기반일까

새로고침은 유지되는데, 탭 닫으면 사라진다.

즉 디스크보다 현재 탭 세션 생명주기 에 더 가까운 저장소였다.

그래서

임시 폼 상태
일회성 데이터
현재 탭 작업 상태

같은 데 잘 맞는다.

저장소 선택은 “보안 모델 선택”

예전엔 저장소를 단순 기능 기준으로 골랐다.

"어디가 편하지?"

근데 지금은 오히려

자동 전송 필요한가?
JS 접근 허용할 건가?
XSS 위험은?
CSRF 위험은?
탭 공유 필요한가?
영구 저장 필요한가?

같은 걸 먼저 보게 된다.

정리

개인적으로는 이렇게쓰는것 같다.

인증 정보

Cookie (HttpOnly + Secure + SameSite)

서버 자동 인증
JS 접근 차단
XSS 대응 강화

사용자 설정

LocalStorage

다크모드
언어 설정
최근 본 상품

민감하지 않고, 브라우저 재시작 후에도 유지되어야 하는 값.

임시 상태

SessionStorage

작성 중 폼
현재 탭 상태
임시 UI 흐름

탭 종료 시 자연스럽게 제거되는 게 오히려 장점이다.

Browser 저장소