Logo ari Space

Security 시리즈

한국어로 정리한 프론트엔드 인증·보안 자료

HttpOnly 쿠키 하이브리드 인증을 실제 서비스에 1년 4개월 운영하며 얻은 결정과 회고를 4편으로 정리했습니다. 각 글을 어떤 순서로 읽어야 흐름이 이어지는지, 어떤 결정 지점이 가장 어려웠는지 본인 관점에서 큐레이션 했습니다.

읽는 순서

  1. 1단계 — 결정

    "토큰을 어디에 저장할까" — localStorage, 서버 세션, HttpOnly 쿠키 하이브리드 비교

    “토큰을 어디에 보관할까” 결정에 1주일을 썼습니다. localStorage·서버 세션·HttpOnly 쿠키 하이브리드 세 가지를 같은 기준으로 비교해서, 왜 결국 하이브리드를 택했는지 정리했습니다.

  2. 2단계 — 한계 직시

    "HttpOnly만 믿으면 안 된다" — XSS 활성 상태와 SameSite Lax의 한계

    하이브리드를 운영하다 “HttpOnly 쿠키면 안전하다”는 인식의 빈틈을 발견했습니다. XSS 활성 상태에서도 토큰이 오용되는 시나리오, SameSite Lax의 세 가지 구조적 허점을 코드 예시와 함께 설명합니다.

  3. 3단계 — 헷갈렸던 지점

    인증 아키텍처에서 가장 헷갈렸던 다섯 지점 — 토큰 위치, 토큰 관리 분산, HttpOnly, SameSite Lax, CSRF 논증

    1편·2편을 쓰면서 실제로 가장 시간이 많이 든 다섯 지점을 따로 모았습니다. 토큰 관리가 두 레이어로 나뉜 구조 정당화, CSRF “성립하지 않음” 논증의 어려움까지.

  4. 4단계 — 회고

    "다시 한다면 어떻게 할까" — 인증 아키텍처 회고와 개선안

    1년 4개월 운영 후 다시 한다면 바꿀 다섯 가지: 백엔드 Set-Cookie 회귀, CSP 1일차 도입, Refresh Token Rotation, 쿠키 Path/Prefix 보수화, 인증 활동 로깅.

Live Demo

보안 강화 데모 로그인 + 공격 시도 패널

위 4편의 글에서 다룬 보안 설계가 실제로 어떻게 동작하는지 직접 만져보는 데모를 준비 중입니다. HttpOnly·SameSite·Refresh Rotation·CSRF·CSP·rate limit이 적용된 가입/로그인 시스템과, 8가지 공격 시도(localStorage 토큰 탈취, document.cookie 읽기, CSRF, refresh token 재사용 등)를 직접 실행해 무엇이 차단되는지 눈으로 확인할 수 있는 패널을 함께 제공할 예정입니다. 곧 공개합니다.

관련 1차 출처

함께 일하고 싶다면

채용 관련해 이야기 나누고 싶다면 우측 하단 챗 위젯의 “사람에게” 탭으로 메시지를 보내거나 메일을 보내주시길 바랍니다.