Next.js 보안 헤더 실전 설정: CSP, HSTS, X-Frame-Options를 운영 관점으로 적용하기
💡 Key Takeaways
- 보안 헤더는 한 번에 강하게 적용하기보다 관찰 가능한 단계로 점진 적용해야 장애를 줄일 수 있습니다.
- CSP는 script-src만 보는 것이 아니라 이미지, 폰트, API 도메인까지 전체 리소스 흐름을 기준으로 설계해야 합니다.
- HSTS는 롤백이 어려우므로 서브도메인 구조를 먼저 점검한 뒤 적용해야 합니다.
- 보안 강도와 사용자 경험 사이의 균형을 로그 기반으로 관리해야 장기적으로 유지됩니다.
Next.js 보안 헤더 실전 설정
보안 헤더는 대부분의 팀이 "해야 한다는 건 아는데 언제 적용해야 할지"를 고민하는 영역입니다. 실제로 프로젝트 후반에 급하게 붙이면, 외부 스크립트 차단이나 임베드 깨짐 같은 부작용이 자주 발생합니다. 그래서 보안 헤더는 릴리스 직전 작업이 아니라, 운영 중 점진적으로 강화해야 하는 설정입니다.
특히 Next.js 기반 서비스는 마케팅 도구, 분석 스크립트, 이미지 CDN, 서드파티 위젯을 함께 사용하는 경우가 많습니다. 이 환경에서 강한 정책을 한 번에 적용하면 예상치 못한 차단이 생길 수 있습니다. 중요한 것은 "완벽한 헤더"가 아니라 "서비스를 깨지 않으면서 공격 표면을 줄이는 순서"를 설계하는 것입니다.
1. 우선순위: 클릭재킹, MIME 스니핑, 전송 보안
초기에는 난이도가 낮고 효과가 즉시 나타나는 헤더부터 적용하는 것이 좋습니다. X-Frame-Options 또는 frame-ancestors로 클릭재킹을 줄이고, X-Content-Type-Options: nosniff로 MIME 스니핑 위험을 줄이며, HTTPS 전용 운영이 안정화된 뒤 HSTS를 적용하는 순서가 일반적으로 안전합니다.
이 단계에서 중요한 것은 "왜 이 헤더를 켰는지"를 팀 문서에 남기는 것입니다. 나중에 문제가 생겼을 때, 단순히 켜고 끄는 대응이 아니라 의도에 맞는 조정을 할 수 있습니다. 보안 설정이 코드에서 가장 빨리 잊히는 이유는 설명이 함께 남아 있지 않기 때문입니다.
2. CSP는 정책 문장보다 리소스 지도 작성이 먼저
CSP(Content-Security-Policy)는 가장 강력하지만 가장 까다로운 설정입니다. 많은 팀이 예시 문자열을 복사해서 넣고 끝내는데, 이 방식은 운영에서 거의 항상 문제를 만듭니다. 먼저 해야 할 일은 우리 서비스가 어떤 도메인에서 스크립트, 이미지, 폰트, API를 가져오는지 목록화하는 것입니다.
실무에서는 report-only 모드로 시작해 위반 로그를 수집한 뒤, 실제 차단 모드로 전환하는 방식이 안전합니다. 특히 마케팅 팀이 새 도구를 붙이는 경우가 많다면, CSP 변경 요청 프로세스를 배포 프로세스에 포함해야 합니다. 보안팀만 CSP를 관리하면 제품 속도와 충돌하기 쉽습니다.
3. HSTS 적용 전 반드시 확인할 항목
HSTS는 HTTPS 강제를 통해 중간자 공격 위험을 줄이는 데 효과적이지만, 한 번 강하게 적용하면 되돌리기 어렵습니다. includeSubDomains를 사용할 경우 서브도메인 중 하나라도 HTTPS 준비가 안 되어 있으면 실제 장애가 납니다. 그래서 도메인 구조 점검 없이 일괄 적용하면 안 됩니다.
권장 접근은 낮은 max-age로 시작해 문제가 없는지 관찰한 뒤 점진적으로 늘리는 것입니다. 운영팀이 인증서 자동 갱신 상태를 모니터링하고, 신규 서브도메인 생성 프로세스에도 HTTPS 의무를 넣어야 HSTS를 안전하게 유지할 수 있습니다.
4. Next.js에서의 적용 위치와 운영 방식
Next.js에서는 next.config의 headers() 또는 프록시 레이어에서 보안 헤더를 관리할 수 있습니다. 어디에 두든 중요한 건 "환경별로 다른 정책"을 명시적으로 관리하는 것입니다. 로컬 개발과 운영 정책을 완전히 동일하게 강제하면 개발 속도가 지나치게 떨어질 수 있으므로, 테스트 환경에서 점진 검증을 거쳐 운영에 반영하는 흐름이 현실적입니다.
또한 보안 헤더는 설정값 자체보다 관측이 중요합니다. CSP 위반 로그, iframe 차단 이슈, mixed content 경고를 주기적으로 확인해야 정책을 유지할 수 있습니다. 보안은 일회성 작업이 아니라, 배포와 함께 움직이는 운영 루틴입니다.
5. 팀 관점 체크리스트
보안 헤더 적용 전후로 아래 항목을 확인하면 시행착오를 줄일 수 있습니다.
- 현재 서비스 리소스 도메인 목록이 최신 상태인가
- CSP를 report-only로 충분히 관찰했는가
- HSTS 적용 전 모든 서브도메인이 HTTPS 준비됐는가
- 마케팅/운영 도구 추가 시 보안 정책 갱신 절차가 있는가
- 장애 시 임시 완화 절차와 책임자가 문서화됐는가
보안 헤더는 공격을 "완전히 막는 마법"이 아니라, 위험을 줄이는 방어층입니다. 복붙 설정보다 서비스 맥락에 맞는 점진 도입이 중요하고, 로그 기반으로 조정할 때 비로소 운영 가능한 보안 체계가 됩니다.