출시 전 마지막 응답 보안 헤더 점검하기

문제 상황

보안 헤더는 보통 한 파일이나 한 팀만 소유하지 않습니다. 애플리케이션 middleware가 CSP를 만들고 framework가 X-Content-Type-Options를 추가하며, 리버스 프록시가 Referrer-Policy를 바꾸고 CDN이 일부 호스트에만 HSTS를 붙일 수 있습니다. 그래서 로컬 페이지가 정상이어도 마지막 공개 HTML 응답에는 보호가 빠질 수 있습니다. 리다이렉트 캡처도 함정이 됩니다. 첫 301 응답은 강하지만 도착 페이지는 약할 수 있고, Report-Only는 위반을 막지 않는데도 CSP처럼 보입니다. 일반 템플릿을 복사하는 것만으로는 부족합니다. 보안 전송이 아닌 곳에서 받은 HSTS는 무시되고 includeSubDomains는 준비되지 않은 호스트를 막을 수 있으며, CSP는 필요한 리소스를 깨뜨리고 COOP나 COEP는 popup과 asset 동작을 바꿀 수 있습니다. 유효한 출시 점검은 실제 엣지 응답을 확인하고 어느 블록을 분석했는지 남기며, 존재와 시행을 구분하고, 내부 URL이나 Authorization 값을 외부에 노출하지 않으면서도 헤더 검토가 전체 애플리케이션 보안의 한 부분일 뿐임을 명확히 해야 합니다.

공식 출처와 표준

다음 공식 문서는 이 작업 흐름에서 다루는 형식과 보안 경계의 기준입니다. 도구별 실행 검증은 위에 별도로 기록합니다.

• RFC 9110: HTTP Semantics

  RFC Editor / IETF

• RFC 6797: HTTP Strict Transport Security (HSTS)

  RFC Editor / IETF

• Content Security Policy Level 3

  World Wide Web Consortium (W3C)

이럴 때 사용하세요

• 공개 웹 앱, 문서 사이트, 관리자 화면, 로그인 페이지의 첫 프로덕션 출시가 다가왔을 때 사용합니다.
• framework, middleware, CDN, load balancer, 리버스 프록시 이전으로 응답 헤더가 바뀌었을 가능성이 있을 때 사용합니다.
• CSP를 Content-Security-Policy-Report-Only에서 시행 정책으로 전환할 때 사용합니다.
• apex, www, 언어 경로, 리다이렉트, 오류, 인증 경로가 서로 다른 헤더를 보낼 수 있을 때 사용합니다.
• 대상이 비공개이거나 민감해 원격 URL 스캐너 대신 로컬 붙여넣기 검토가 필요할 때 사용합니다.

단계

1. 1단계

   출시를 대표할 응답 목록 정하기

   canonical HTML 페이지, apex와 www 호스트, 언어 경로, 로그인 또는 계정 화면, 오류 응답 하나, 리다이렉트 진입점을 적습니다. API 응답은 자체 정책 동작이 중요할 때만 넣으세요. 문서 전용 헤더를 모든 JSON이나 이미지 응답에 요구할 필요는 없습니다.

2. 2단계

   개발 서버가 아닌 배포 엣지 캡처하기

   `curl -I https://example.com/path`를 실행하거나 브라우저 DevTools에서 응답 헤더를 복사합니다. CDN과 프록시를 지난 뒤 사용자가 받는 응답을 캡처하세요. 인증이 필요하면 승인된 로컬 명령이나 DevTools를 사용하고, 증거를 저장하거나 공유하기 전에 Cookie, Authorization, Set-Cookie, token, 내부 주소, request ID를 제거합니다.

3. 3단계

   리다이렉트 경계를 보존하고 마지막 응답 확인하기

   `curl -IL`을 쓸 때 블록 경계와 상태 줄을 유지합니다. 체인을 보안 헤더 확인기에 붙여넣고 표시된 분석 블록이 마지막 응답인지 확인하세요. RFC 6797 HSTS는 보안 전송으로 받은 경우에만 유효하므로 앞선 HTTP-to-HTTPS 리다이렉트도 별도로 봅니다.

4. 4단계

   표현 차이보다 시행 누락부터 해결하기

   HSTS max-age=0, 비었거나 효력이 없는 시행 CSP, 영향이 큰 unsafe CSP source, nosniff 누락, 문서 프레임 보호 누락 순으로 고위험과 경고를 처리합니다. Content-Security-Policy-Report-Only는 보호가 아니라 관찰로 취급하고 반복된 단일값 헤더가 여러 배포 계층에서 주입되는지 확인합니다.

5. 5단계

   집중 분석기로 정책 세부 내용 확인하기

   directive, nonce, hash, source expression, 중복 directive는 CSP Header Analyzer에서 봅니다. 모든 hop, 비밀값 마스킹, 잘못된 줄, 중복 분류가 필요하면 보안 개요 대신 HTTP Header Parser를 함께 사용합니다.

6. 6단계

   헤더 변경 뒤 실제 동작 시험하기

   실제 경로를 다시 열고 로그인, 인가 실패, form, upload, download, embed, popup, worker, font, analytics 동의, 제3자 asset을 실행합니다. CSP report와 브라우저 console도 확인하세요. 필요한 기능을 깨뜨리는 강한 헤더는 완료된 배포가 아닙니다.

7. 7단계

   기록하고 프로덕션에서 같은 점검 반복하기

   비밀정보를 제거한 보고서에 release commit, 시각, host, path, status, 담당 배포 계층을 기록합니다. 프로덕션이 안정된 뒤 같은 행렬을 다시 실행하고 의존성 검토, 인증과 인가, session, TLS, 위협별 테스트는 별도 출시 게이트로 유지합니다.

예시

HTTP/2 200
content-type: text/html; charset=utf-8
strict-transport-security: max-age=63072000; includeSubDomains
content-security-policy: default-src 'self'; object-src 'none'; frame-ancestors 'none'
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=()
cross-origin-opener-policy: same-origin
cross-origin-embedder-policy: require-corp

마지막 응답 블록: 1
응답 종류: 문서
감지된 보안 헤더: 7
누락된 권장 헤더: 0
경고: 0
고위험: 0
시행 CSP와 완성된 COOP/COEP 격리 쌍이 있습니다.

흔한 실수

자주 묻는 질문