대부분의 사이트가 아직 건너뛰는 보안 헤더: 49 실제 감사 데이터

이 보고서를 위해 우리는 감사한 모든 사이트에서 리다이렉트 이후의 최종 홈페이지 응답으로부터 6 보안 헤더를 읽었습니다. 리다이렉트 전 단계에서만 전송된 헤더는 계산되지 않습니다. 브라우저가 이를 페이지에 적용하지 않기 때문입니다. 질문은 고의적으로 좁습니다: 응답이 헤더를 전혀 포함했는가.

49 사이트를 5월 23부터 August 31, 2026까지 감사한 결과, 대부분은 아니었습니다. Permissions-Policy는 그 중 69%에 없고, Referrer-Policy는 65%에, Content-Security-Policy는 61%에, X-Frame-Options는 51%에, X-Content-Type-Options는 43%에, 그리고 Strict-Transport-Security — 6 중 가장 많이 채택된 것은 41%에 있습니다.

방법론: 현재 체크셋에서 도메인당 최신 완료 감사 스냅샷, 대략 5월 23 – August 31, 2026, 49 개별 도메인, 익명화. 각 비율은 홈페이지 응답이 해당 헤더를 포함하지 않은 사이트의 비율입니다. 샘플은 자발적으로 감사를 수행한 소유자들에 의해 자가 선택되었으며, 소규모 및 중간 규모 사이트에 편향되어 있어 웹 전체에서 헤더 채택률을 과소평가할 가능성이 있습니다. 대형 플랫폼은 엣지에서 이를 설정하기 때문입니다. 비율을 장기 꼬리 방향성으로 해석하십시오.

이 수치는 품질이 아니라 존재 여부를 셉니다

측정에 대한 정밀도는 여기서 중요합니다, 왜냐하면 이 숫자가 주장할 수 있는 한계를 설정하기 때문입니다.

이 수치는 사이트당 1 응답, 즉 리다이렉트 이후의 홈페이지를 설명합니다. 존재는 비어 있지 않은 값을 의미하며, 그 이상은 아닙니다. max-age가 1초인 Strict-Transport-Security 헤더도 존재하는 것으로 계산되며, 모든 것을 허용할 만큼 관대한 Content-Security-Policy도 마찬가지입니다. 존재 여부는 정책이 잘 구성되었는지에 대해 아무것도 말해 주지 않습니다.

이는 측정 대상이 무엇인지 고려하면 약한 지표처럼 보입니다. 어떤 값이라도 있는 헤더는 인간이 한 번이라도 서버 설정, CDN 규칙, 또는 미들웨어 파일을 열어 지시어를 입력했다는 증거입니다. 이 측정은 사이트의 구성 계층이 실제로 의도적으로 조정되었는지를 테스트합니다 — 실패율이 흥미로운 부분이며, 통과율은 그렇지 않습니다.

이미 배포한 헤더가 실제로 무언가를 보호하는지는 두 가지 세부 사항이 결정합니다:

• Report-only CSP는 아무것도 강제하지 않습니다. Content-Security-Policy-Report-Only는 위반을 차단하지 않고 기록만 합니다. 시작하기에는 올바른 방법이지만, 강제하는 Content-Security-Policy 헤더가 배포되기 전까지 정책은 아무것도 보호하지 않습니다.
• frame-ancestors와 X-Frame-Options는 서로 다른 클라이언트에 도달합니다. CSP frame-ancestors 지시어가 더 나은 제어이며, 오래된 클라이언트는 레거시 X-Frame-Options 헤더만 읽습니다. 둘 다 배포하십시오.

채택은 헤더가 얼마나 오래된지를 추적하며, 얼마나 어려운지는 추적하지 않습니다.

실패율 순서는 역순에 가깝습니다. 6개 중 가장 오래된 HSTS는 모든 주요 CDN 대시보드에서 토글로 전환할 수 있어 가장 많이 채택되었습니다. X-Content-Type-Options와 X-Frame-Options는 공식 후속 제품보다 훨씬 오래된 공급업체 관행이며, 중간에 위치합니다. Referrer-Policy와 Permissions-Policy는 가장 최신이며, 가장 적게 채택된 두 헤더이며, Permissions-Policy는 일반 호스트가 귀하를 대신해 설정하지 않으므로 마지막에 위치합니다.

이들 중 어느 것도 엔지니어링 측면에서 다른 것보다 어렵지 않습니다. 6개 중 5개는 서버 블록, CDN 규칙 또는 엣지 미들웨어 파일에 한 줄로 정적 라인으로 존재하며, 애플리케이션 변경 없이 행동 위험이 없습니다. 이들을 구분하는 것은 기본값을 축적한 기간과 블로그 게시물, 체크리스트, 프레임워크 템플릿이 얼마나 많이 흡수했는가입니다. 우리는 감사 기록 전체에서 모든 실패 검사를 순위 매김에서 동일한 형태를 보았습니다: 응답 헤더가 목록 상단을 지배하며, 정규화, 렌더링, 성능보다 앞섭니다. 그 순위는 다른 창, 다른 샘플, 그리고 이전 검사 세트를 다루었으므로 두 세트의 비율은 추세선이 아닙니다 — 그러나 두 경우 모두 헤더가 상단에 있는 위치는 지속적인 발견입니다.

다른 구조적 이유는 가시성 부재입니다. 누락된 헤더는 화면에서 아무것도 바꾸지 않습니다. CMS가 경고하지도, 빌드가 실패하지도, 대시보드가 빨간색으로 변하지도 않습니다. 부재는 원시 응답을 검사하는 것만이 관찰할 수 있으며, 이는 감사, 브라우저 보안 상태, 그리고 자동화된 독자의 증가 비율이 정확히 수행하는 일입니다. 이는 렌더 패리티에서 발견한 동일한 비대칭성입니다: 인간이 브라우저에서 보는 것과 기계가 HTTP를 통해 받는 것이 조용히 달라졌습니다.

각 헤더가 보호하는 것

Strict-Transport-Security는 브라우저에게 귀하의 도메인에 대해 명시된 기간 동안 평문 HTTP을 거부하도록 지시하며, 이는 네트워크에서 공격자가 귀하의 http:// → https:// 리디렉션이 발생하기 전에 가로챌 수 있는 리디렉션 창을 닫습니다. 또한 max-age를 충족하는 유일한 헤더이며, 나중에 HTTPS를 깨더라도 브라우저가 이를 존중합니다. 짧게 시작하고, 모든 서브도메인과 자산이 TLS를 통해 깨끗하게 제공되는지 확인한 뒤 확장합니다.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Content-Security-Policy는 스크립트, 스타일, 프레임 및 연결이 어디에서 오는지를 제한합니다. 이 헤더는 범주를 방지하는 것이 아니라 사건을 포함하는 유일한 헤더입니다: 태그 매니저가 손상되거나 사용자 입력이 DOM에 도달하면 CSP가 삽입된 스크립트가 실행될 수 있는지 또는 선택한 서버에 도달할 수 있는지를 결정합니다. 또한 작동 중인 페이지를 깨뜨릴 수 있는 유일한 헤더이므로 아래 순서의 마지막에 배치됩니다.

Content-Security-Policy-Report-Only: default-src 'self'

X-Frame-Options는 다른 출처가 귀하의 페이지를 프레임에 넣을 수 있는지 여부를 선언합니다. 없으면 귀하의 인터페이스가 공격자의 페이지에 투명 오버레이 아래에 삽입되어 사용자가 귀하의 사이트에 있는 것처럼 믿고 클릭할 수 있습니다. 현대 CSP는 frame-ancestors를 사용해 이를 더 잘 표현합니다; 오래된 클라이언트는 레거시 헤더만 읽으므로 둘 다 배포하십시오.

X-Frame-Options: DENY

X-Content-Type-Options는 선언된 Content-Type가 잘못된 경우 브라우저가 응답 유형을 추측하지 못하도록 합니다. 스니핑은 텍스트로 제공되는 업로드된 파일이 스크립트로 실행될 수 있는 방법입니다. 헤더는 정확히 1 유효한 값을 가집니다.

X-Content-Type-Options: nosniff

Referrer-Policy는 현재 URL의 어느 정도가 아웃바운드 클릭 및 서브리소스 로드 시 제3자에게 전달되는지를 관리합니다. 귀하의 URL은 캠페인 매개변수, 내부 검색 쿼리, 계정 식별자 및 때로는 토큰을 포함하며, 페이지의 모든 분석 픽셀과 글꼴 CDN은 수신자입니다. 주요 브라우저는 합리적인 기본값에 합의했지만, 기본값은 사용자 에이전트가 귀하를 대신해 결정하며 클라이언트마다 다릅니다; 헤더를 전송하면 정책이 명시적이 되고 민감한 URL을 처리하는 사이트가 same-origin와 같은 더 엄격한 것을 선택할 수 있습니다.

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

Permissions-Policy는 문서와 그에 포함된 프레임이 요청할 수 있는 브라우저 기능—카메라, 마이크, 지리 위치 및 기타 강력한 기능 목록—을 결정합니다. 헤더가 없으면 비활성화하지 않은 모든 것이 페이지의 모든 스크립트, 작성하지 않은 타사 태그를 포함해 사용할 수 있습니다. 사용하지 않는 것은 거부하십시오.

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

먼저 4 단일문을 배포한 뒤 CSP에 한낮을 보냅니다

보호 가치와 배포 위험은 정확히 1 헤더에 대해 의견이 다르며, 수정 순서는 배포를 선호하도록 의견 차이를 해결합니다.

graph TD
    A[자신의 응답 헤더를 읽으십시오] --> B[1 배포: 짧은 max-age를 가진 HSTS]
    B --> C[2 배포: nosniff, Referrer-Policy, Permissions-Policy, X-Frame-Options]
    C --> D[TLS가 모든 곳에서 확인되면 HSTS max-age를 확장하십시오]
    D --> E[보고 전용 모드에서 CSP]
    E --> F{위반 보고가 깔끔합니다?}
    F -->|아니오| G[소스 조정, 보고 전용 유지]
    G --> F
    F -->|예| H[CSP 적용, frame-ancestors 추가]

배포 1 — HSTS, 짧게. 높은 보호 가치를 지니며, 사이트가 이미 HTTPS을 어디서나 제공할 때 거의 위험이 없습니다. 먼저 적당한 max-age을 설정하여 잊은 서브도메인에서 TLS 문제가 발생해도 복구 가능하도록 합니다.

배포 2 — 4개의 정적 라인을 함께. nosniff, Referrer-Policy, Permissions-Policy 및 X-Frame-Options는 애플리케이션 종속성이 없는 정적 값입니다. 이들은 6 헤더 중 4개이며, 이러한 실패율에서 평균 사이트가 놓치고 있는 대부분은. 별도로 단계화할 이유가 없습니다.

그 다음에 HSTS 확장, 도메인 아래 모든 호스트가 TLS를 통해 깨끗하게 제공되는 것을 확인한 후.

마지막 — 보고 전용 모드에서 CSP. Deploy Content-Security-Policy-Report-Only, 실제 트래픽에서 위반 사항을 수집하고 실제로 의존하는 스크립트 및 연결 소스를 열거합니다. 그 다음에 헤더를 강제 모드로 전환하고 frame-ancestors를 X-Frame-Options 라인과 함께 추가합니다. 가장 큰 노력, 시퀀스에서 마지막, 왜냐하면 목록에서 유일하게 작동 중인 페이지를 다운시킬 수 있는 항목이기 때문입니다.

1 명령에서 자신의 헤더를 읽습니다

전체 측정은 터미널에서 재현 가능합니다. 리다이렉트를 따라가세요, 브라우저가 적용하는 것은 최종 응답이기 때문입니다:

curl -sSL -o /dev/null -D - https://example.com/ \
  | grep -iE 'strict-transport-security|content-security-policy|x-frame-options|x-content-type-options|referrer-policy|permissions-policy'

돌아오지 않는 모든 라인은 홈페이지가 보내지 않는 헤더입니다. 모든 6가 돌아오면 존재 표시줄이 지워지고 다음 질문 — 정책 자체가 좋은가 — 를 물어볼 가치가 있습니다. 유료 SEOReport 진단은 누락된 각 헤더를 이를 해결하는 값과 함께 나열합니다.

이 데이터 세트의 헤더가 누락된 것은 어렵거나 논쟁이 있기 때문이 아닙니다. 일반적인 웹사이트 생활에서 그 부재가 드러나지 않기 때문에 누락됩니다: 오류도 없고, 시각적 변화도 없고, 빌드 실패도 없습니다. 통과하는 사이트는 한 번 누군가가 찾아갔던 곳이며, 그 단일 배포는 아직 대부분이 갖지 못한 상태로 남아 있습니다.