가장 쉬운 보안 헤더가 이기고 있다. 가장 쉬운 보안 헤더가 쉬우니까.
바보같이 당연하게 들리지만 이야기 전체가 이거다.
블로그 글 대신 실제 채택 데이터를 보면, “한 줄 설정” 헤더와 “아키텍처 부채를 드러낼” 헤더 사이의 격차가 엄청나다. 팀들은 기꺼이 X-Content-Type-Options를 켠다. X-Frame-Options도 종종 설정한다. HSTS를 관리하는 곳도 꽤 있다. 그다음 진짜 Content Security Policy나 현대적 교차 출처 격리 헤더를 요청하면 절벽이다 — 서버 스니펫 복사가 아닌 애플리케이션 변경이 필요한 것 말이다.
데이터가 이에 대해 노골적이다.
숫자가 보여주는 것
HTTP Archive Web Almanac 같은 대규모 웹 측정 프로젝트가 일관되게 같은 그림을 그린다:
높은 채택 (40-50%+):
X-Content-Type-Options: nosniff— 한 줄, 설정 없음, 아무것도 안 깨뜨림. 가장 높은 채택.X-Frame-Options— 역시 단순. 대부분의 프레임워크가 기본 추가.
중간 채택 (20-30%):
Strict-Transport-Security— 클라우드 플랫폼과 CDN이 자동 설정해주니까 예상보다 높다. 하지만 많은 사이트가 짧은max-age를 설정하고includeSubDomains를 빼서 보호를 제한한다.
낮은 채택 (10-15%):
Content-Security-Policy— 가장 중요하고 가장 덜 배포된. CSP가 있는 사이트 중 상당수가unsafe-inline을 써서 CSP가 제공하는 XSS 보호를 무력화한다. unsafe-inline과 unsafe-eval 없는 기능적 CSP는 전체 사이트 대비 한 자릿수 초반.Referrer-Policy— 성장 중이지만 아직 보편과 멀다.Permissions-Policy— 신규 헤더, 브라우저 지원 이력이 패치워크, 매우 낮은 채택.
매우 낮은 채택 (<5%):
Cross-Origin-Opener-Policy,Cross-Origin-Resource-Policy,Cross-Origin-Embedder-Policy— 교차 출처 격리 3인조. 거의 전적으로 대형 테크 플랫폼에 국한.
CSP 격차가 핵심이다
다른 헤더는 전부 설정 한 줄이다. CSP는 엔지니어링 프로젝트다.
X-Content-Type-Options: nosniff 설정은 2초 걸리고 거의 아무것도 안 깨뜨린다. 기능적 CSP 설정은 페이지의 모든 스크립트를 감사하고, 인라인 스크립트를 nonce나 해시로 교체하고, 모든 리소스 오리진을 제어하고, 광범위하게 테스트하는 것이다. 수년간 축적된 프론트엔드 코드, 서드파티 분석 태그, 임베디드 위젯, 마케팅 스크립트가 있는 사이트라면 몇 주 작업이다.
팀은 합리적인 일을 한다: 쉬운 헤더를 설정하고, 스캐너 검사를 통과하고, CSP를 무기한 미룬다.
unsafe-inline 문제
CSP 채택을 관대하게 세도 기능적 숫자는 보이는 것보다 나쁘다. 스크립트에 'unsafe-inline'을 포함하는 CSP는 임의의 인라인 스크립트 실행을 허용한다 — XSS 익스플로잇이 정확히 하는 짓. 정책이 존재한다. 다만 설계된 주요 공격에 대해 보호하지 않는다.
왜 unsafe-inline을 쓰나? 없으면 애플리케이션이 깨져서. 인라인 이벤트 핸들러, 템플릿의 인라인 스크립트 태그, 스크립트를 주입하는 서드파티 위젯 — 엄격한 CSP에서 전부 실패한다. 고치려면 리팩터링이 필요하다. unsafe-inline 추가는 한 줄이면 된다.
업계가 너무 강력한 헤더를 만들어서 대부분의 사이트가 그 힘을 무력화하는 모드에서만 배포할 수 있다.
HSTS: 가깝지만 아직
HSTS 채택이 CSP보다 나아 보이는 건 부분적으로 Cloudflare 같은 CDN이 자동 설정해주니까. 하지만 HSTS 품질이 천차만별이다.
max-age=86400(하루)은 최소한의 보호를 제공한다. 하루짜리 max-age는 공격자가 피해자가 24시간만 사이트를 안 방문하면 HSTS 보호가 만료된다는 뜻이다. 권장 최소는 1년(31536000초). 많은 사이트가 훨씬 아래다.
좀비 헤더
X-XSS-Protection이 놀라울 정도로 많은 사이트에 남아있다. Chrome이 2019년에 XSS Auditor를 제거했다. Firefox는 가져본 적 없다. 이 헤더는 현재 어떤 브라우저에서도 아무것도 안 한다. 그런데 10년 전 블로그에서 복사해서 한 번도 정리 안 한 서버 설정에 남아있다.
거의 “카고 컬트 보안”의 마커다.
이게 말해주는 것
보안 헤더 채택에 명확한 패턴이 있다: 깨뜨릴 위험 없는 한 줄 설정 변경이면 채택이 괜찮다. 애플리케이션을 이해해야 하면 채택이 무너진다.
가장 중요한 헤더 — CSP와 preload이 있는 HSTS — 가 정확히 가장 많은 노력이 필요한 헤더다. 가장 쉽게 배포되는 헤더 — nosniff, X-Frame-Options — 는 현대 브라우저에서 가장 적은 한계 보호를 제공한다.
자기 헤더를 보고 CSP 빼고 전부 초록색이면, 어려운 부분을 아직 안 한 것이다. 어려운 부분에 보호가 실제로 산다.