이번 편의 결과물: 이 과목이 07~08편에서 택할 토큰 보관 방식과 그 이유를 결정합니다. 코드는 바꾸지 않습니다. · 다루는 개념: 세션 쿠키 vs JWT, 저장 위치별 보안 트레이드오프, 보호 라우트가 막는 것과 못 막는 것
이 편에서 만드는 파일
개념 편입니다. 새로 만들거나 고치는 파일이 없습니다. 07편에서 api/auth.js, 08편에서 라우트 가드를 만들 때 이 편의 결정을 그대로 적용합니다.
개념 정리
세션 쿠키와 JWT는 “누가 상태를 기억하는가”가 다르다
| 방식 | 상태를 기억하는 주체 | 서버 부담 | 만료 처리 |
|---|---|---|---|
| 세션 쿠키 | 서버(세션 저장소) | 세션 목록을 서버가 관리 | 서버에서 즉시 무효화 가능 |
| JWT | 클라이언트(토큰 자체에 정보 포함) | 서버는 검증만 함 | 만료 전까지는 서버가 강제로 무효화하기 어려움 |
이 과목의 mock API는 로그인 성공 시 JWT 형태의 토큰 문자열을 반환한다고 가정합니다. 실제 서버 구현은 범위 밖입니다.
토큰을 어디에 둘 것인가 — 세 가지 선택지
| 저장 위치 | 새로고침 유지 | XSS 노출 위험 | CSRF 노출 위험 |
|---|---|---|---|
| 메모리(변수, 상태) | 유지 안 됨 | 낮음 | 없음 |
localStorage | 유지됨 | 높음(스크립트가 직접 읽을 수 있음) | 없음 |
httpOnly 쿠키 | 유지됨 | 낮음(스크립트가 못 읽음) | 있음(별도 방어 필요) |
OWASP는 세션 식별자를 localStorage에 저장하지 말라고 권고합니다. 페이지에 삽입된 악성 스크립트(XSS)가 localStorage를 그대로 읽어갈 수 있기 때문입니다. httpOnly 쿠키는 자바스크립트로 읽을 수 없어 이 위험을 줄이지만, 서버가 쿠키를 발급·검증하는 구조가 필요해 이 과목의 mock API 범위를 넘어섭니다.
이 과목은 메모리 보관 + 새로고침 시 재조회 방식을 택합니다. 토큰을 컴포넌트 상태(또는 Zustand 스토어의 비영속 필드)에만 두고, 새로고침하면 로그인 화면으로 돌아가거나 mock API의 “내 정보” 엔드포인트로 세션을 다시 확인합니다. localStorage 저장보다 사용자 편의는 줄지만, XSS 위험을 실습 단계에서부터 피하는 습관을 들이기 위한 선택입니다.
보호 라우트가 막는 것과 못 막는 것
보호 라우트(인증 가드)는 미인증 사용자가 화면을 렌더링하지 못하게 막습니다. 하지만 다음은 막지 못합니다.
- 서버 API를 직접 호출하는 것(브라우저 개발자 도구로 요청을 재현할 수 있음)
- 토큰이 탈취된 뒤의 오남용(토큰 자체가 유효하면 서버는 정상 요청으로 판단)
- 서버 쪽 권한 검사 없이 클라이언트 라우팅만으로 데이터를 보호하는 것
즉 보호 라우트는 화면 접근을 통제하는 사용자 경험 장치이지 보안의 전부가 아닙니다. 실제 데이터 보호는 서버가 매 요청마다 토큰을 검증해야 합니다. 이 과목의 mock API도 형식상 이 검증을 흉내 냅니다.
직접 해보기
토큰을 localStorage에 저장했다고 가정하고, 페이지에 삽입된 스크립트 한 줄이 토큰을 훔쳐가는 시나리오를 문장으로 적어보세요.
악성 스크립트가 localStorage.getItem으로 토큰 값을 읽어 외부 서버로 전송하면, 공격자는 그 토큰으로 사용자인 척 API를 호출할 수 있습니다. httpOnly 쿠키나 메모리 보관은 스크립트가 값을 직접 읽지 못하게 해 이 경로를 막습니다.
자주 하는 실수
| 증상 | 원인 | 고치는 법 |
|---|---|---|
| 새로고침하면 로그인이 풀린다 | 메모리 보관 방식의 당연한 특성을 버그로 착각 | 재조회 로직을 추가하거나, 편의가 더 중요하면 트레이드오프를 문서화하고 다른 방식 채택 |
| 보호 라우트만 있으면 안전하다고 착각한다 | 클라이언트 라우팅과 서버 인가를 혼동 | 서버가 매 요청마다 토큰을 검증하는지 별도로 확인 |
| 토큰을 콘솔에 로그로 남긴다 | 디버깅 습관 | 배포 코드에서 토큰 값을 로그로 남기지 않기 |