보안 가이드

보안 헤더 고르는 법: 아직 필요한 것, 쓸모없어진 것, 해가 되는 것

온라인의 보안 헤더 목록 대부분은 갱신이 멈춰, 이미 사라진 헤더를 아직 권합니다. MDN은 X-XSS-Protection을 폐지되었고 비표준이라고 표시하며, 원래 안전한 사이트에 XSS 취약점을 만들 수 있다고 경고합니다. 지금 설정할 헤더와 제거할 헤더를 정리합니다.

게시 2026-09-05 업데이트 2026-10-04 최종 확인 2026-09-05 6분 읽기

헤더 설정 예시는 어디에나 있습니다. 문제는 그 대부분이 갱신을 멈췄다는 것입니다. 몇 년 전에는 옳았던 목록을 복사하면, 역할을 다한 헤더와 함께 오히려 해가 될 수 있는 헤더까지 들여오게 됩니다.

① 지금 설정할 가치가 있는 6가지

본 사이트의 보안 헤더 검사 도구는 이 6가지를 기준으로 평가합니다. 폐지된 헤더는 일부러 제외했습니다.

6가지 헤더와 각각의 역할

Content-Security-Policy: 스크립트와 리소스를 어디서 불러올 수 있는지 선언합니다. XSS로 할 수 있는 일을 좁히는 핵심 통제입니다. frame-ancestors로 페이지 삽입도 제어합니다
Strict-Transport-Security: 브라우저에 항상 HTTPS로 다시 오라고 알려, 첫 평문 요청의 틈을 막습니다(max-age와 includeSubDomains)
X-Frame-Options: 다른 사이트가 프레임으로 삽입하는 것을 거부합니다. 클릭재킹 방어입니다. 실무에서는 CSP의 frame-ancestors와 함께 설정합니다
X-Content-Type-Options: nosniff. 브라우저가 내용을 보고 타입을 추측하는 것을 막아, 업로드된 파일이 엉뚱한 것으로 해석되는 사고를 줄입니다
Referrer-Policy: 다음 사이트로 넘어가는 리퍼러를 제한해 URL에 들어간 정보의 유출을 줄입니다(애초에 URL에 비밀을 넣지 않는다는 전제에서)
Permissions-Policy: 카메라, 마이크, 위치 정보 같은 브라우저 기능을 기본으로 끕니다. 쓰지 않는 것은 닫아 두세요

순서가 중요하다: 아무것도 망가뜨리지 않는 것부터

X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy는 확실하고 화면 표시를 망가뜨릴 가능성이 낮으므로 먼저 넣어도 됩니다. Strict-Transport-Security는 모든 경로에서 HTTPS가 작동한 뒤로 미루세요. 브라우저가 기억하기 때문에 되돌리기 어렵습니다.

CSP는 마지막에, 단계적으로 넣습니다. 기능에 가장 큰 영향을 주므로, 한 번에 엄격하게 하면 정상 기능이 망가집니다. CSP 빌더로 차근차근 만들어 가세요.

② 역할을 다한 것

Expect-CT: 2021년 6월 이후 대부분 쓸모없음

MDN은 이 헤더를 Deprecated로 표시하고, Google Chrome과 다른 Chromium 기반 브라우저만 구현했으며 Chromium이 이제 CT를 기본으로 강제하므로 버전 107부터 이 헤더를 폐지했다고 설명합니다. 같은 페이지의 주석은 "Expect-CT는 2021년 6월 이후 대부분 쓸모없다"고 덧붙입니다.

즉 브라우저가 기본으로 하게 되었으므로, 사이트가 지시할 것이 남아 있지 않습니다. 새로 추가할 이유가 없습니다.

③ 이제는 해가 될 수 있는 것

X-XSS-Protection: 폐지, 비표준, 그리고 XSS를 만들 수 있다

MDN은 이 헤더에 Deprecated와 Non-standard 표시를 모두 붙이고, 이렇게 경고합니다. "이 기능은 CSP를 지원하지 않는 오래된 웹 브라우저의 사용자를 보호할 수는 있지만, 경우에 따라 X-XSS-Protection은 원래 안전한 웹사이트에 XSS 취약점을 만들 수 있다."

권고는 분명합니다. "XSS 필터링 대신 Content-Security-Policy를 쓸 것을 권한다."

이것이 "헤더는 많을수록 좋다"에 대한 결정적인 반례입니다. 선의로 추가한 설정이 조건에 따라서는 공격 지점이 될 수 있습니다. 보내고 있지 않다면 추가하지 말고, 이미 보내고 있다면 제거를 계획하세요. 근본 결함에 대해서는 XSS란을 참고하세요.

오래된 목록의 모습

CSP, HSTS, X-Frame-Options, nosniff에 더해
X-XSS-Protection: 1; mode=block
Expect-CT: max-age=…
Public-Key-Pins: …

목록은 더 길고, 어떤 검사 도구는 점수를 더 높게 줄지도 모릅니다. 하지만 현재 브라우저에서 그 추가 항목들은 아무 효과가 없거나 해가 될 수 있습니다.

지금의 실무

CSP를 중심에 두고, 나머지 다섯 가지가 받쳐 줍니다.

폐지된 헤더는 추가하지 않고, 있으면 제거합니다. CSP의 질, 특히 'unsafe-inline'을 얼마나 없앴는지에 들인 노력이 목록을 늘리는 것보다 훨씬 큰 실제 방어가 됩니다.

전제: 헤더는 취약점 자체를 고치지 않는다

애플리케이션 결함(XSS, 인가 누락, 업로드)

헤더를 아무리 늘려도 이것은 사라지지 않는다

↓ 결함이 터졌을 때

헤더가 제어하는 것

데이터를 어디로 보낼 수 있나 · 프레임 삽입이 되나 · 평문을 허용하나 = 번지는 범위의 제한

헤더는 취약점이 있는지 없는지를 바꾸지 않습니다. 취약점이 있을 때 피해가 어디까지 닿는지를 바꿉니다.

XSS 결함이 있는 사이트에 CSP를 추가해도 XSS는 사라지지 않고, 그것으로 할 수 있는 일이 좁아질 뿐입니다. 그래서 순서는 애플리케이션 결함을 고치고, 그다음 헤더를 또 하나의 방어선으로 겹치는 것입니다. 반대도 성립합니다. 헤더 점수가 만점이라고 사이트가 안전하다는 증거는 아닙니다.

내 사이트 점검하기

실제로 반환되는 것을 측정한다

설정 파일이 아니라 응답을 보세요. 리버스 프록시, CDN, 프레임워크, 애플리케이션이 각각 헤더를 추가하거나 덮어쓰므로, 설정한 것과 실제로 보내지는 것이 늘 같지는 않습니다. 본 사이트의 헤더 검사 도구는 URL을 직접 측정합니다.

결과에서 폐지된 헤더를 찾는다

X-XSS-Protection이나 Expect-CT가 돌아온다면 제거를 계획하세요. 특히 앞의 것은, 위에서 본 것처럼 취약점을 만들 수 있다고 문서화되어 있습니다.

아무것도 망가뜨리지 않는 네 가지를 추가한다

X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, 그리고 쓰지 않는 기능을 닫는 Permissions-Policy. 확실하고, 화면 표시에 영향을 줄 가능성이 낮습니다.

HSTS는 HTTPS가 완전히 작동할 때까지 미룬다

Strict-Transport-Security는 브라우저가 기억하므로, HTTPS가 불안정한 상태에서 켜면 복구가 고통스럽습니다. 먼저 모든 경로가 HTTPS로 제공되는지 확인하세요. 인증서의 기초는 Let's Encrypt란에 있습니다.

CSP는 단계적으로 도입해 조여 간다

느슨하게 시작해 조여 가되, 'unsafe-inline' 제거를 목표로 삼으세요. 이것을 어디까지 해내느냐가 CSP의 보호 수준을 대부분 정합니다. CSP 빌더로 만들고, 내친김에 보안 기본 체크리스트의 나머지 항목도 확인하세요.

본 사이트의 견해: 복사한 설정은 출처가 얼마나 오래되었느냐가 안전을 정한다

보안 헤더는 복사해서 붙여 넣는 설정의 대표격이고, 그래서 출처가 얼마나 오래되었느냐가 결과의 안전을 정합니다. 이 글에 나온 두 헤더도 한때는 옳았습니다. X-XSS-Protection은 그 이상입니다. 그 시절의 권고가 오늘의 경고가 되었습니다.

본 사이트의 입장은 헤더 설정을 한 번 끝내는 작업이 아니라 가끔 다시 보는 설정으로 다루는 것입니다. 그리고 검사 도구의 점수를 목표로 삼지 않습니다. 폐지된 헤더를 추가해서 점수가 오를 수도 있기 때문입니다. 시간은 목록의 길이가 아니라 CSP의 질에 쓰세요.

출처(공식)

MDN Web Docs, "X-XSS-Protection" — developer.mozilla.org (Deprecated와 Non-standard 표시, 원래 안전한 웹사이트에 XSS 취약점을 만들 수 있다는 경고, 대신 CSP를 쓰라는 권고)
MDN Web Docs, "Expect-CT" — developer.mozilla.org (Deprecated 표시, Chromium 107에서의 폐지와 그 이유, 2021년 6월 이후 대부분 쓸모없다는 주석)

둘 다 2026년 9월 5일에 확인했습니다.

다음으로 읽기

FAQ

QX-XSS-Protection을 설정해야 하나요?

아닙니다. MDN은 이 헤더를 Deprecated(폐지)이자 Non-standard(비표준)로 표시하고, CSP를 지원하지 않는 오래된 브라우저의 사용자를 보호할 수는 있지만 경우에 따라 X-XSS-Protection이 원래 안전한 사이트에 XSS 취약점을 만들 수 있다고 경고합니다. 권고도 분명합니다. XSS 필터링 대신 Content-Security-Policy를 쓰라는 것입니다. 보내고 있지 않다면 추가하지 말고, 보내고 있다면 제거할 계획을 세우세요.

QExpect-CT는 아직 필요한가요?

필요 없습니다. MDN은 이것을 Deprecated로 표시하고, Google Chrome과 다른 Chromium 기반 브라우저만 구현했으며 Chromium이 이제 Certificate Transparency를 기본으로 강제하므로 버전 107부터 이 헤더를 폐지했다고 설명합니다. 같은 페이지의 주석은 이 헤더가 2021년 6월 이후 대부분 쓸모없다고 적고 있습니다. 새로 추가할 이유가 없습니다.

Q그러면 무엇을 설정해야 하나요?

본 사이트의 헤더 검사 도구가 평가하는 6가지가 실무적인 출발점입니다. Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy입니다. 폐지된 헤더는 일부러 이 목록에서 뺐습니다. 순서는 확실하고 무언가를 망가뜨릴 가능성이 낮은 것(nosniff, X-Frame-Options)부터 추가하고, 기능에 가장 큰 영향을 주는 CSP는 단계적으로 도입하세요.

Q헤더를 전부 설정하면 사이트가 안전한가요?

아닙니다. 헤더는 애플리케이션의 취약점을 고치지 않습니다. 피해가 어디까지 번지는지를 제한할 뿐입니다. XSS 결함이 있는 사이트에 CSP를 추가해도 XSS는 사라지지 않고, 그것으로 할 수 있는 일이 좁아질 뿐입니다. 애플리케이션 결함을 먼저 고치고, 헤더는 또 하나의 방어선으로 겹쳐 두세요. 반대로 헤더 검사 도구의 만점도 사이트가 안전하다는 증거가 아닙니다.