보안 헤더 점검 체크리스트

사용자가 실제로 받는 응답을 점검하세요

원본 서버나 로컬 서버가 아니라 리디렉션 이후 최종 HTTPS 응답을 확인하세요. CDN, 프록시, 프레임워크가 브라우저까지 오는 동안 헤더를 바꿀 수 있습니다.

정책은 실제 앱과 맞아야 합니다. 지나치게 엄격한 복사본은 로그인·결제·이미지·API를 깨뜨리고, 지나치게 느슨한 정책은 보호 효과가 거의 없습니다.

헤더별 점검

1. Content-Security-Policy

   스크립트, 스타일, 이미지, 연결, 프레임에 실제 필요한 출처부터 정의하세요. 앱이 정상 동작하는 범위에서 와일드카드와 unsafe 허용을 줄입니다.

2. Strict-Transport-Security

   호스트 전체가 HTTPS로 동작함을 확인한 뒤 브라우저가 HTTPS를 유지하게 하세요. 모든 하위 도메인이 준비된 경우에만 하위 도메인을 포함합니다.

3. 프레임 보호

   CSP frame-ancestors로 사이트를 삽입할 수 있는 대상을 정하세요. 같은 의도와 맞는다면 구형 클라이언트를 위해 X-Frame-Options도 설정합니다.

4. X-Content-Type-Options

   nosniff를 설정하고 스크립트와 스타일을 올바른 Content-Type으로 제공하세요.

5. Referrer-Policy

   다른 사이트에 원본 URL 정보를 얼마나 전달할지 정하세요. 정책과 무관하게 URL에는 비밀값이나 개인정보를 넣지 마세요.

6. Permissions-Policy

   앱이 쓰지 않는 카메라, 마이크, 위치 기능을 끄고 실제 기능에 필요한 권한만 허용하세요.

7. 핵심 경로 재점검

   홈, 로그인, 대시보드, API, 오류 응답, 정적 파일을 각각 확인하세요. 한 경로의 헤더가 전체 적용을 보장하지 않습니다.

잘못된 안도감의 징후

• 홈은 통과하지만 인증·오류 경로의 헤더가 다름
• CSP가 있어도 모든 호스트·인라인 스크립트·동적 실행을 허용함
• 모든 하위 도메인이 HTTPS를 지원하기 전에 HSTS를 확대함
• 플랫폼 설정에는 있지만 최종 응답에는 헤더가 없음

작고 관찰 가능한 단계로 바꾸세요

정책 변경마다 브라우저 개발자 도구와 앱 테스트를 확인하세요. 가능하면 CSP를 보고 전용 모드로 먼저 적용해 위반을 검토한 뒤, 의도한 기능에 필요한 최소 정책을 강제합니다.

다음 점검 이어가기