XSS 방지를 위한 HttpOnly Cookie 도입 시의 트레이드오프 및 구현 분석

Securing auth in a large-scale production system: three industry-standard architectures — and why none survived a closer look

Bilaniuc Dragos2026년 5월 26일20분advanced

AI 요약

Context

Next.js와 AWS Cognito 기반의 조합으로 구성된 대규모 멀티 프론트엔드 시스템에서 토큰이 non-HttpOnly 쿠키에 저장되어 XSS 공격에 노출된 취약점 발견. 100개 이상의 마이크로서비스가 Bearer Token 형식을 기대하는 레거시 계약과 Vercel의 서버리스 과금 모델이라는 제약 조건이 공존하는 상황.

Technical Solution

XSS 원천 차단을 위해 토큰 저장소를 Client-side JS 접근이 불가능한 HttpOnly Cookie로 전환하는 구조 설계
100개 이상의 하위 서비스의 API 계약을 유지하기 위해 Authorization 헤더로 토큰을 변환하여 전달하는 프록시 레이어 검토
Vercel 서버리스 함수 비용 최적화를 위해 Client-side 호출(65-70%)의 서버 경유 시 발생하는 Wall-clock time 증가분 분석
CSRF 공격 가능성 증대에 따른 추가 보안 레이어 도입 및 토큰 갱신(Refresh Token) 로직의 서버 사이드 이관 설계
단순 아키텍처 패턴 적용이 아닌, 실제 구현 레벨에서의 런타임 비용과 인프라 제약 사항을 반영한 최적 경로 탐색

실천 포인트

1. 아키텍처 결정 시 '정답' 패턴이 아닌 '구현 비용'과 '인프라 제약'을 우선 고려했는가?

2. 보안 패치 도입으로 인해 발생하는 새로운 공격 표면(예: XSS 해결 후 CSRF 발생)을 식별했는가?

3. 서버리스 환경에서 프록시 레이어 추가 시 요청당 실행 시간 증가에 따른 비용 시뮬레이션을 수행했는가?

4. 하위 마이크로서비스의 API 계약(Contract) 변경 시의 전파 범위와 조정 비용을 산정했는가?

태그

#XSS #CSRF #Next.js #AWS Cognito #httpOnly Cookie

원문 읽기