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

우리가 수행하는 모든 감사는 홈페이지의 응답 헤더를 읽습니다. 그들 중 6는 통과/불통 과정을 거칩니다; report-only CSP와 교차 출처 격리 쌍은 맥락을 위해 보고되며 결함으로 계산되지 않습니다. 읽기는 일반 HTTP fetch에서 발생합니다 — AI 크롤러가 받는 것과 동일한 캡처이며, 리디렉션 후 최종 응답에서도 발생합니다. 따라서 사전 리디렉션 단계에서만 헤더를 설정하는 사이트는 그에 대한 신용을 얻지 못합니다. 엔진이 묻는 질문은 고의적으로 좁습니다: 응답이 헤더를 전혀 포함했는가. 49 사이트가 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%에 있습니다. 방법론: 현재 체크셋에서 도메인당 최신 완료 감사 스냅샷, 대략 23 – August 31, 2026 사이, 49 개별 도메인, 익명화. 각 비율은 홈페이지 응답이 해당 헤더를 포함하지 않은 사이트의 비율입니다. 샘플은 자발적으로 감사를 수행한 소유자들에 의해 선택되었으며, 소규모 및 중간 규모 사이트에 편향되어 있어 전체 웹에서 헤더 채택을 과소평가할 가능성이 있습니다. 대형 플랫폼은 엣지에서 이를 설정하기 때문입니다. 비율을 장기 꼬리 방향성으로 간주하십시오.

체크는 헤더가 존재하는지 여부를 묻습니다, 좋은지 여부는 묻지 않습니다

측정에 대한 정밀도는 여기서 중요합니다, 왜냐하면 이 숫자들이 주장할 수 있는 한계를 설정하기 때문입니다. 엔진은 홈페이지만 읽습니다 — 하나의 URL, 하나의 응답 — 그리고 해당 캡처가 사용 가능할 때는 일반 HTTP 캡처에서 헤더 값을 가져오며, 그렇지 않을 때는 다른 홈페이지 캡처로 대체합니다. 존재는 비어 있지 않은 값을 의미합니다. 지시어에 대한 등급은 없습니다: Strict-Transport-Security의 max-age이 1초이면 통과하며, Content-Security-Policy가 아무 것이나 허용할 만큼 관대하면 통과합니다. 통과 판정이 정책이 잘 구성되었다고 말하지는 않습니다. 이는 측정 항목을 고려하지 않으면 약한 지표처럼 보입니다. 어떤 값이라도 있는 헤더는 인간이 한 번은 서버 구성을 열었고, CDN 규칙이나 미들웨어 파일을 열어 지시어를 입력했다는 증거입니다. 체크는 사이트의 구성 계층이 실제로 의도적으로 조작된 적이 있는지를 테스트합니다 — 그래서 실패율이 흥미로운 부분이며, 통과율은 그렇지 않습니다. 심각도는 헤더별로 할당되며, 균일하게는 아닙니다. Strict-Transport-Security와 Content-Security-Policy는 높은 심각도로 실패합니다. X-Frame-Options, X-Content-Type-Options, Referrer-Policy 및 Permissions-Policy는 중간 수준에서 실패합니다. Cross-origin isolation, COOP 및 COEP 쌍은 정보 제공용으로만 사용됩니다 — 헤더 중 하나가 있으면 통과하고, 그렇지 않으면 정보 판결을 내리며, 실패는 절대 발생하지 않습니다. 이는 해당 헤더가 기본 방어가 아니라 고급 브라우저 기능을 제어하기 때문입니다. 보고서를 읽기 전에 알아두면 좋은 두 가지 동작이 있습니다:

• Report-only CSP는 CSP 검사를 만족하지 않습니다. 엔진은 Content-Security-Policy를 구체적으로 확인합니다. Content-Security-Policy-Report-Only만 실행되는 사이트는 시행 검사를 실패하고, 위반이 기록되지만 차단되지 않는 별도의 정보 판결을 받습니다. 그 판결은 두 CSP 헤더 중 하나가 있을 때만 존재합니다.
• frame-ancestors는 X-Frame-Options 검사를 만족하지 않습니다. 엔진은 X-Frame-Options 헤더를 직접 읽습니다. frame-ancestors 지시어를 포함한 현대 CSP는 더 나은 제어이며, 레거시 헤더를 제거하고 이를 제공하는 사이트는 여전히 해당 검사를 실패합니다.

코드에는 한 가지 플랫폼 편의가 있습니다. 응답이 Vercel에서 오고 페이지가 Vercel의 BotID 스크립트를 로드하면, CSP가 없더라도 여전히 실패하지만, 고위험이 아니라 중간 위험으로 처리되며, BotID이 인라인 스크립트 허용을 필요로 하여 엄격한 CSP 시행과 충돌한다는 설명이 포함됩니다. 사이트는 첫 1KB에 HTML 주석을 삽입해 예를 들어 <!-- seoreport-ignore: vercel-botid-csp -->과 같은 이유를 명시함으로써 이 제약을 의도적으로 문서화할 수 있습니다. 이유가 CSP 또는 BotID이라면 검사는 실패 대신 정보 판결로 전환됩니다. 이것이 가족에서 유일한 탈출구이며, 실제 플랫폼 제약이 방치처럼 보이지 않도록 하기 위해 존재합니다.

채택은 헤더가 얼마나 오래되었는지, 얼마나 어려운지에 따라 달라집니다.

실패율 순서는 역순에 가깝습니다. 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는 문서와 그에 포함된 프레임이 요청할 수 있는 브라우저 기능(카메라, 마이크, 지리 위치 및 기타 강력한 기능 목록)을 결정합니다. 헤더가 없으면 비활성화하지 않은 모든 것이 페이지의 모든 스크립트, 작성하지 않은 제3자 태그를 포함해 사용할 수 있습니다. 사용하지 않는 것은 거부합니다.

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

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

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

배포 1 — HSTS, 짧게. 가장 높은 심각도이며, 사이트가 이미 HTTPS을 어디서나 제공할 때 거의 위험이 없습니다. 먼저 적당한 max-age을 설정하여 잊혀진 서브도메인에서 TLS 문제가 복구 가능하도록 합니다. 배포 2 — 4개의 중간 심각도 라인을 함께. nosniff, Referrer-Policy, Permissions-Policy 및 X-Frame-Options는 애플리케이션 종속성이 없는 정적 값입니다. 이들은 4의 6 검사이며, 이러한 실패율에서 평균 사이트가 놓치고 있는 대부분은. 별도로 단계화할 이유가 없습니다. 그 다음에 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가 돌아오면 존재 표시줄이 지워지고 다음 질문 — 정책 자체가 좋은지 — 가 물어볼 가치가 있습니다. 우리의 무료 보고서는 모든 감사를 동일하게 읽고 각 누락된 헤더와 그 값을 나열합니다. 이 데이터 세트의 헤더가 누락된 것은 어렵거나 논쟁이 있기 때문이 아닙니다. 일반적인 웹사이트 생활에서 그 부재가 드러나지 않기 때문에 누락됩니다: 오류도 없고, 시각적 변화도 없고, 빌드 실패도 없습니다. 통과하는 사이트는 한 번 누군가가 찾아갔던 곳이며, 그 단일 배포는 아직 대부분이 갖지 않은 상태로 남아 있습니다.