43강에서 우리는 XSS 공격으로 로컬 스토리지에 저장된 apiKey가 탈취되는 시나리오를 봤다.
44강에서는 그에 대한 중요한 대안을 다룬다.
핵심은 이 문장이다.
“쿠키는 fetch 요청 시 자동으로 헤더에 포함된다.”
쿠키의 가장 중요한 특징은 이것이다.
즉,
쿠키는 브라우저가 관리하는 인증 수단
서버가 응답 시 다음과 같이 쿠키를 설정하면
Set-Cookie: apiKey=xxxx; Path=/;
이후 브라우저는:
Cookie 헤더에 포함시켜 전송Cookie: apiKey=xxxx
👉 개발자는 fetch 코드에서 쿠키를 직접 넣지 않는다.
const response = await fetch("http://localhost:8080/api/v1/posts/1", {
credentials: "include"
});
credentials: "include"👉 이 코드만으로도
👉 쿠키에 저장된 apiKey가 자동 전송된다
const apiKey = localStorage.getItem("apiKey");
const response = await fetch("http://localhost:8080/api/v1/posts/1", {
headers: {
Authorization: `Bearer ${apiKey}`
}
});
const response = await fetch("http://localhost:8080/api/v1/posts/1", {
credentials: "include"
});
| 구분 | 쿠키 | 로컬 스토리지 |
|---|---|---|
| 프론트엔드에서 조작 가능 | ✅ 가능 (HttpOnly 쿠키는 ❌) | ✅ 가능 |
| 백엔드에서 조작 가능 | ✅ 가능 (Set-Cookie 헤더) | ❌ 불가능 |
| fetch 시 자동 전송 | ✅ 자동 전송 (Cookie 헤더) | ❌ 수동 전송 |
| 용량 제한 | 약 4KB | 5~10MB |
| 만료 기간 | 설정 가능 | 기본 영구 |
| 도메인 제한 | 설정 가능 | 도메인별 분리 |
| XSS 보안 | HttpOnly 설정 시 접근 불가 | JS에서 자유 접근 |
👉 43강에서 본 대규모 계정 탈취 시나리오 차단 가능
즉,
인증 실수를 구조적으로 줄여준다
44강의 핵심 메시지는 이것이다.
“인증 정보는 개발자가 들고 있지 말고,
브라우저에게 맡겨라.”
44강은 이렇게 요약할 수 있다.
“자동으로 전송되는 인증 정보는
자동으로 지켜진다.”