HttpOnly 쿠키 하이브리드 인증 구조를 운영하면서 아쉬웠던 결정들을 돌아보고, 백엔드 직접 Set-Cookie 회귀, CSP 1일차 도입, Refresh Token Rotation, 쿠키 Path/Prefix 보수화, 인증 활동 로깅까지 다음에 다시 한다면 바꿀 다섯 가지를 정리합니다.
1편·2편을 쓰면서 실제로 가장 시간이 많이 든 다섯 지점을 따로 정리합니다. 토큰 저장 위치 결정, 로그인-갱신 비대칭 구조 정당화, HttpOnly의 진짜 보호 범위, SameSite Lax의 안전 신화, CSRF "성립하지 않음" 논증의 어려움까지.
HttpOnly 쿠키가 XSS 활성 상태에서도 토큰을 완전히 지켜주지 못하는 시나리오, SameSite Lax의 세 가지 구조적 한계, CSP·Refresh Token Rotation·rate limit 같은 추가 대응책을 정리합니다.
localStorage, 서버 세션, HttpOnly 쿠키 하이브리드 세 가지 토큰 저장 전략을 비교하고, refreshToken만 HttpOnly 쿠키로 보호하는 하이브리드 구조를 채택한 의사결정 과정과 인증 플로우를 정리합니다.