가장 흔한 10가지 보안 헤더 실수 (그리고 고치는 법)

HTTP 응답 헤더는 설정 몇 줄로 모든 방문자를 즉시 보호하는 드문 보안 통제입니다. 그래서 틀리기도 쉽습니다 — 복사·붙여넣기는 쉽고 테스트는 어렵기 때문입니다. 스캔 결과에 반복해서 나타나는 열 가지 문제입니다.

1. HSTS 없음 (또는 preload 없는 HSTS)

Strict-Transport-Security가 없으면 HTTPS 리디렉션 전의 평문 요청 한 번이 가로채질 수 있습니다. 긴 max-age를 설정하고 서브도메인을 포함하세요:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

모든 서브도메인이 HTTPS 전용이 된 뒤에만 preload를 추가하세요 — 빠르게 되돌리기 어렵습니다.

2. unsafe-inline을 허용하는 Content-Security-Policy

script-src 'unsafe-inline'은 CSP가 막으려는 바로 그 XSS 구멍을 다시 엽니다. nonce나 해시로 옮기세요:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'

3. 영원히 report-only 모드로 배포

Content-Security-Policy-Report-Only는 롤아웃 단계용입니다. 많은 사이트가 몇 달씩 그대로 두어 보고서만 모으고 아무것도 강제하지 않습니다. report-only로 위반을 찾고, 잠잠해지면 강제 헤더로 전환하세요.

4. frame-ancestors 대신 X-Frame-Options

X-Frame-Options는 레거시이며 허용 목록을 표현할 수 없습니다. 최신 브라우저가 따르는 CSP 지시문을 선호하세요:

Content-Security-Policy: frame-ancestors 'self'

5. X-Content-Type-Options 누락

X-Content-Type-Options: nosniff가 없으면 브라우저가 응답을 MIME 스니핑하여 텍스트로 제공한 것을 실행할 수 있습니다. 단점 없는 한 줄 헤더이니 항상 설정하세요.

6. 위험하거나 없는 Referrer-Policy

기본값은 전체 URL(쿼리 문자열의 토큰 포함)을 제3자에게 유출합니다. 안전하고 호환성이 넓은 선택은 다음과 같습니다:

Referrer-Policy: strict-origin-when-cross-origin

7. Permissions-Policy를 브라우저 기본값으로 둠

앱이 카메라, 마이크, 위치를 쓰지 않는다면 명시하세요. 그러면 손상된 스크립트도 쓸 수 없습니다:

Permissions-Policy: camera=(), microphone=(), geolocation=()

8. HTML에는 헤더를 설정하지만 API에는 안 함

프런트엔드 프레임워크가 적용하는 헤더는 API 경로, 리디렉션, 오류 페이지를 자주 놓칩니다. 스캐너는 그 경로를 직접 테스트합니다. 보안 헤더는 엣지 — 리버스 프록시, CDN, 플랫폼 미들웨어 — 에서 설정해 적용 범위를 균일하게 하세요.

9. 여러 계층에서 온 충돌하는 헤더

앱과 CDN이 모두 Content-Security-Policy를 설정하면 브라우저가 두 헤더를 보고 *교집합*을 적용하여 조용히 기능을 깨뜨릴 수 있습니다. 권위 있는 한 계층을 정하고 중복을 제거하세요.

10. 민감한 응답을 캐싱함

인증된 페이지와 개인 데이터가 담긴 API 응답은 공유 프록시가 캐시해서는 안 됩니다:

Cache-Control: no-store

재스캔으로 확인하세요

헤더는 상호작용하므로 작은 배치로 바꾸고 매번 재스캔하세요. 결과 읽기가 처음이라면 웹사이트 보안 스캔 보고서 읽는 법부터 시작하세요. 이 헤더 아래의 전송 계층은 사이트를 위험에 빠뜨리는 SSL/TLS 설정 오류를 참고하세요. 전체 헤더 검사는 매 스캔마다 실행됩니다 — 기능 페이지의 모든 검사를 보세요.