HSTS와 보안 헤더 완벽 가이드: 한 줄로 SSL 스트립·클릭재킹·XSS를 막는 HTTP 응답 헤더 설정법

응답 헤더 한 줄이 공격 한 부류를 통째로 막아낼 때가 있습니다. 보안 헤더는 서버가 브라우저에게 "이 사이트에서는 이렇게 행동하라"고 내리는 명령이고, 그 명령을 내리지 않으면 브라우저는 호환성 우선의 느슨한 기본값으로 동작합니다. 이 글은 HSTS·CSP를 비롯한 핵심 보안 헤더를 한 줄씩 뜯어보며, 무엇을 막는지·어떻게 켜는지·어디서 발이 걸리는지를 복붙 가능한 설정과 함께 정리합니다.

웹 서버에 TLS를 잘 깔고 인증서를 A 등급으로 받아 놨다고 해서 전송 계층 방어가 끝난 것은 아닙니다. 암호화는 "통신이 도청되지 않게" 해 주지만, 브라우저가 그 암호화를 언제·어떻게 쓰는지, 외부에서 들어온 스크립트를 실행할지, 다른 사이트가 내 화면을 프레임에 가둬도 되는지 같은 행동 규칙까지 정해 주지는 않습니다. 그 규칙을 정하는 것이 보안 헤더입니다.

핵심은 비용 대비 효율입니다. 헤더 한 줄을 추가하는 데 드는 노력은 분 단위지만, 막아내는 공격은 SSL 스트립, 클릭재킹, MIME 혼동, XSS처럼 부류 전체입니다. 그런데도 단 하나의 보안 헤더도 없는 사이트가 여전히 흔합니다. 명시적으로 안전한 동작을 지시하지 않으면 브라우저는 알아서 안전하게 동작하지 않습니다 — 오히려 호환성을 위해 느슨한 쪽으로 기웁니다.

아래에서는 가장 까다롭지만 가치가 큰 HSTS와 CSP를 먼저 깊게 다루고, 부작용 없이 즉시 켤 수 있는 헤더들을 묶어서 본 뒤, 실제 서버에 적용하는 방법과 흔히 빠지는 함정, 그리고 검증 명령까지 이어가겠습니다.

HSTS: 브라우저에게 "항상 HTTPS만" 강제하기

HSTS(HTTP Strict Transport Security)는 브라우저에게 "이 사이트는 앞으로 무조건 HTTPS로만 접속하라"고 못 박는 헤더입니다. SSL Labs에서 A+ 등급을 받기 위한 마지막 한 조각이기도 합니다.

어떤 틈을 막는가

HTTPS를 정상적으로 운영하고 있어도 미묘한 구멍이 하나 남습니다. 사용자가 주소창에 example.com만 입력하면, 브라우저는 흔히 암호화되지 않은 평문 HTTP로 먼저 접속을 시도하고, 서버가 그제서야 301/302로 HTTPS로 안내합니다. 바로 이 "암호화되기 직전의 첫 평문 요청" 한 번이 공격의 발판이 됩니다. 같은 네트워크에 있는 공격자가 이 순간을 가로채 HTTPS로의 전환을 가로막거나 사용자를 가짜 사이트로 유도하는 것 — 이것이 SSL 스트립(SSL stripping) 공격입니다.

HSTS는 이 첫 평문 요청 자체를 없애 버립니다. 한 번이라도 HSTS 헤더를 받은 브라우저는, 그 이후로는 해당 도메인을 처음부터 HTTPS로만 다룹니다. 사용자가 http://를 직접 치거나 평문 링크를 눌러도 브라우저가 내부적으로 HTTPS로 바꿔 보냅니다. 평문 연결이 아예 발생하지 않으니, 그 틈을 노리는 공격은 성립할 수가 없습니다. (헤더의 세부 동작과 옵션은 MDN의 Strict-Transport-Security 문서에 정리되어 있습니다.)

헤더 한 줄을 토큰 단위로 해부하기

HSTS 헤더의 완전한 형태는 다음과 같습니다.

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

이 헤더가 "강력하지만 까다롭다"는 평을 듣는 이유가 바로 이 세 토큰에 있습니다. 각각의 의미와 위험도를 정확히 구분해야 합니다.

max-age는 단순히 유효 기간입니다. includeSubDomains부터는 신중해야 합니다. 이 옵션을 켜는 순간, 아직 HTTPS를 지원하지 않는 하위 도메인이 있다면 그 도메인은 즉시 접속이 막힙니다. 그래서 이 옵션을 켜기 전에 운영 중인 모든 서브도메인 목록을 따로 정리해, 전부 HTTPS로 응답하는지 먼저 확인해야 합니다. 운영하다 잊고 방치한 legacy.example.com 같은 평문 하위 도메인 하나가 전체 장애의 원인이 되곤 합니다.

preload는 "끄기 버튼이 없는" 옵션이라고 생각하라

preload의 위험만은 따로 강조하겠습니다. 사이트가 브라우저 사전 목록에 한 번 올라가면, 그것을 내리는 일은 대단히 느립니다. 제거를 신청해도, 이미 사용자 기기에 배포되어 돌고 있는 수많은 브라우저에서 그 항목이 실제로 사라지기까지는 긴 시간이 걸립니다.

이게 왜 무서울까요. 어떤 이유로든 — 인증서 갱신 실패, 설정 사고, 평문만 쓰는 하위 도메인이 갑자기 필요해진 상황 — 사이트가 HTTPS를 제공하지 못하게 되면, preload에 등록된 도메인은 그냥 "접속 불가" 상태가 됩니다. 브라우저는 HTTPS를 고집하는데 정작 HTTPS가 안 되니, 사용자에게는 사이트로 들어갈 우회로가 없습니다. 게다가 이 상황을 즉시 되돌릴 수도 없습니다.

그래서 권장되는 도입 순서는 철저히 단계적입니다.

1. 짧은 max-age(예: 며칠~몇 시간)로 시작해 사이트가 멀쩡한지 관찰한다.
2. 문제가 없으면 max-age를 점차 늘려 1년 수준까지 키운다.
3. 모든 하위 도메인이 HTTPS를 지원함을 확인한 뒤에만 includeSubDomains를 켠다.
4. 위 모든 것이 충분히 안정적이라고 확신이 선 다음에야 비로소 preload를 신청한다.

서두를 이유가 없습니다. preload는 켜기는 쉬워도 빠르게 끌 수 없다는 사실 하나만 기억하면 됩니다.

등급보다 의미가 먼저

충분한 max-age를 가진 HSTS가 들어가면 SSL Labs A+에 도달할 수 있습니다. 다만 A+라는 글자 자체보다 중요한 것은, HSTS가 실제로 무엇을 막고 어떤 위험을 동반하는지 이해하고 안전하게 적용하는 일입니다. 등급 욕심에 preload를 덜컥 켰다가 되돌릴 수 없는 곤경에 빠지는 것은 본말 전도입니다.

Content-Security-Policy: 가장 세지만 가장 손이 많이 가는 헤더

보안 헤더 중 방어력이 가장 강한 동시에 설정 난이도도 가장 높은 것이 CSP(Content-Security-Policy)입니다. 한 권의 책으로도 모자랄 만큼 깊은 주제지만, 여기서는 핵심 개념과 실무에서 사고 없이 도입하는 절차에 집중합니다.

CSP가 겨누는 표적: XSS

CSP의 1차 목표는 교차 사이트 스크립팅(XSS, Cross-Site Scripting)을 막는 것입니다. XSS는 공격자가 당신의 페이지에 악성 스크립트를 끼워 넣어, 그것이 다른 사용자의 브라우저에서 실행되게 만드는 공격입니다. 이를 통해 세션을 탈취하고, 화면을 변조하고, 사용자 정보를 빼냅니다. 새로 등장한 기법이 아니라 수십 년째 끈질기게 살아남은 부류로, OWASP Top 10에서도 인젝션 범주 안에서 수년째 상위권을 지키고 있습니다. 2026년 현재도 사정은 다르지 않고, 그래서 브라우저 차원에서 한 겹을 더 쳐 주는 CSP의 가치가 여전합니다.

CSP의 발상은 단순하고 강력합니다. 브라우저에게 "이 페이지에서 실행하거나 불러올 수 있는 자원의 출처는 이것들뿐"이라고 명시적으로 화이트리스트를 건네는 것입니다. 목록에 없는 출처의 스크립트는, 설령 공격자가 페이지 본문에 주입하는 데 성공했더라도, 브라우저가 실행을 거부합니다. 주입에는 성공해도 실행에는 실패하는 구조 — 이것이 CSP가 만드는 방어선입니다. (지시어별 정확한 의미는 MDN의 Content-Security-Policy 문서를 곁에 두고 작성하는 편이 안전합니다.)

왜 그렇게 손이 많이 가는가

강력함의 대가가 곧 까다로움입니다. 정책을 엄격하게 짜면, 공격 스크립트뿐 아니라 정당한 자원까지 함께 차단되어 사이트가 깨질 수 있습니다. 현대 웹 페이지는 자체 스크립트, 분석 도구, 폰트 CDN, 외부 위젯, 이미지 호스트 등 수많은 출처에서 자원을 끌어옵니다. CSP는 이 모두를 빠짐없이 허용 목록에 적어 줘야 하고, 하나라도 누락되면 해당 기능이 즉시 동작을 멈춥니다.

결국 줄타기입니다. 너무 느슨하면 보호 효과가 사라지고, 너무 빡빡하면 멀쩡한 기능이 죽습니다. 그 균형점을 찾는 과정이 CSP의 본질적 어려움입니다.

사고 없이 도입하는 법: 관찰(Report-Only) 모드부터

다행히 CSP에는 실제로 차단은 하지 않고 위반 사항을 보고만 하는 관찰 모드가 있습니다. 강제 헤더(Content-Security-Policy) 대신 보고 전용 헤더를 쓰면, 운영 중인 사이트 동작에는 전혀 영향을 주지 않으면서 "이 정책을 진짜로 강제했다면 무엇이 차단됐을지"를 보고받을 수 있습니다.

# 강제하지 않고 위반만 수집하는 관찰 모드 헤더
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

도입 절차는 다음과 같습니다.

1. 원하는 정책을 관찰 모드로 먼저 배포한다(사이트 동작에 영향 없음).
2. 일정 기간 실제 트래픽에서 위반 보고를 수집한다.
3. 보고를 분석해, 차단될 뻔했던 정당한 자원의 출처를 정책에 추가한다.
4. 더 이상 정당한 자원이 걸리지 않을 때까지 2~3을 반복한다.
5. 정책이 충분히 다듬어졌으면 비로소 관찰 헤더를 강제 헤더로 전환한다.

이렇게 하면 사이트를 한 번도 깨뜨리지 않으면서 CSP를 안착시킬 수 있습니다. 한 번에 완벽한 정책을 쓰려 하지 말고, 점진적으로 깎아 나가는 것이 유일하게 현실적인 방법입니다. 그리고 사이트가 바뀌면 정책도 함께 갱신돼야 하므로, CSP는 "한 번 켜고 끝"이 아니라 지속적으로 관리되는 대상입니다.

한 가지 함정을 덧붙입니다. 어렵게 다듬은 정책이 실은 우회 가능한 경우가 의외로 많습니다. 흔히 쓰는 'unsafe-inline'을 허용하거나, 인기 CDN 도메인을 통째로 화이트리스트에 넣는 식의 정책은 보기엔 그럴듯해도 실제로는 XSS를 거의 막지 못합니다(공격자가 그 CDN에 올라간 임의의 스크립트나 인라인 코드를 악용할 수 있기 때문입니다). 그래서 강제로 전환하기 전에 CSP Evaluator에 정책을 한 번 붙여 보길 권합니다. 작성한 정책을 넣으면 약한 지시어와 우회 지점을 짚어 줍니다. "관찰 모드로 충분히 다듬었다"고 믿었던 정책이 이 도구에서 우회 가능 판정을 받는 일은 드물지 않습니다.

곧바로 켜도 되는 헤더들

CSP만큼 손이 가지 않으면서, 켜는 즉시 효과를 보고 부작용은 거의 없는 헤더들이 있습니다. 대개 한 줄이면 끝나고 사이트를 깨뜨릴 위험이 낮아, 가장 먼저 깔아 두기 좋은 것들입니다. (각 헤더가 받을 수 있는 값과 브라우저 지원 범위는 MDN Web Docs에서 헤더 이름으로 검색하면 바로 확인됩니다.)

X-Content-Type-Options — MIME 스니핑 차단

X-Content-Type-Options: nosniff

브라우저는 때때로 서버가 알려 준 콘텐츠 유형(MIME 타입)을 무시하고 내용을 보고 스스로 유형을 추측합니다. 이 "스니핑"이 악용되면, 이미지인 척 업로드된 파일이 스크립트로 해석되어 실행되는 식의 공격이 가능해집니다. nosniff를 켜면 브라우저가 서버가 선언한 유형을 그대로 따르므로 이런 혼동 공격이 막힙니다. 부작용이 사실상 없으니 항상 켜 두는 것이 맞습니다.

X-Frame-Options — 클릭재킹 차단

X-Frame-Options: DENY

이 헤더는 당신의 페이지가 다른 페이지의 프레임(iframe 등) 안에 삽입되는 것을 막습니다. 클릭재킹(clickjacking) 때문입니다. 공격자는 당신의 사이트를 투명한 프레임에 숨겨 두고 그 위에 가짜 화면을 덮어, 사용자가 가짜 버튼을 누른다고 믿게 만들지만 실제로는 당신의 사이트에서 의도치 않은 동작(예: 송금, 권한 변경)을 실행하게 합니다. DENY는 어떤 프레임 안의 삽입도 금지하고, 같은 출처에서만 허용하려면 SAMEORIGIN을 쓰면 됩니다. (참고로 CSP에는 이를 대체하는 더 현대적인 frame-ancestors 지시어가 있어, CSP를 충실히 갖추면 이 기능을 그쪽에서 처리할 수도 있습니다.)

Referrer-Policy — 리퍼러 정보 누출 통제

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

사용자가 당신의 사이트에서 외부 링크로 넘어갈 때, 브라우저는 "어디서 왔는지"를 알려 주는 리퍼러(Referer) 정보를 상대 사이트에 전달할 수 있습니다. 이 정보에 전체 경로나 쿼리 문자열 같은 민감한 내용이 담겨 외부로 새기도 합니다. 위 값은 합리적인 균형점으로, 같은 출처로 이동할 때는 충분한 정보를 주되, 다른 출처로 나갈 때는 도메인 수준의 최소 정보만 보내 프라이버시를 지킵니다. 불필요한 정보 노출을 줄이는 간단한 한 줄입니다.

Permissions-Policy — 강력한 브라우저 기능 차단

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

이 헤더는 당신의 페이지가 위치 정보·마이크·카메라 같은 강력한 브라우저 기능을 쓸 수 있는지를 통제합니다. 대다수 사이트는 이런 기능을 쓸 일이 없으므로 빈 허용 목록 ()으로 명시적으로 꺼 두면 됩니다. 만에 하나 사이트가 침해되더라도, 공격자가 사용자의 카메라나 위치 같은 민감 기능에 손대지 못하게 미리 차단해 두는 것입니다. 필요 없는 권한은 끄는 것이 공격면 축소의 기본입니다.

실제 적용과 흔한 함정

개념을 알았으니 이제 실제 서버에 어떻게 넣고, 어디서 발이 걸리는지를 봅니다.

어디에 설정하나

보안 헤더는 보통 세 위치 중 한 곳에서 추가합니다 — 웹 서버 설정(Nginx, Apache 등), 애플리케이션 코드, 또는 Cloudflare 같은 프록시/CDN 계층. 어디서 넣든 브라우저가 받는 결과는 비슷하지만, 한곳에서 일관되게 관리하는 것이 혼란과 충돌을 줄이는 핵심입니다.

Nginx라면 server 블록 안에 다음과 같이 넣습니다.

# Nginx server 블록 내 보안 헤더 일괄 설정
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
# CSP는 위에서 설명한 관찰 모드 → 강제 절차를 따라 신중히 도입

여기서 각 줄 끝의 always를 빠뜨리지 마십시오. 이것이 없으면 일부 응답(특히 4xx·5xx 오류 응답)에는 헤더가 붙지 않아, 정작 오류 페이지가 무방비로 노출됩니다.

자주 밟는 지뢰들

다음은 현장에서 반복적으로 나오는 실수들입니다.

• 중복 설정. 서버·애플리케이션·프록시 여러 곳에서 같은 헤더를 동시에 넣으면 값이 충돌하거나 두 번 실리는 일이 생깁니다. 헤더가 어디서 주입되는지 전체 경로를 파악하고 한곳으로 일원화하십시오.
• 오류 페이지의 헤더 누락. 바로 위 always 문제입니다. 정상 페이지엔 헤더가 있는데 오류 응답엔 없으면, 그 응답이 약점이 됩니다.
• CSP를 처음부터 강제 모드로. 관찰 모드를 건너뛰고 곧장 엄격한 CSP를 강제하면 사이트가 깨집니다. 반드시 점진적으로 도입하십시오.
• HSTS preload를 성급하게. 앞서 강조했듯 preload는 빠르게 되돌릴 수 없습니다. 모든 준비가 확실해진 뒤에만 신청하십시오.
• 설정만 하고 검증 안 함. 헤더를 넣어 놓고 실제로 적용됐는지 확인하지 않는 실수가 흔합니다. 검증 방법은 바로 아래에서 다룹니다.

적용됐는지 직접 확인하기

설정한 헤더가 실제 응답에 실렸는지는 직접 요청을 보내 확인하는 것이 가장 확실합니다.

# 자신의 사이트 응답 헤더 전체 보기
curl -sI https://example.com

# 보안 헤더만 추려서 보기
curl -sI https://example.com | grep -iE \
  "strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy"

출력에서 의도한 헤더가 모두 나오는지, 값이 올바른지 확인하십시오. 빠진 것이 있으면 설정을 다시 점검해야 합니다. 명령줄 대신 웹에서 한눈에 보고 싶다면 securityheaders.com이나 Mozilla Observatory를 쓰면 됩니다.

두 온라인 도구의 용도는 조금 다릅니다.

처음에는 securityheaders.com으로 빠진 헤더를 메우고, 그다음 Observatory로 전반을 점검하는 순서가 편합니다. 다만 SSL/TLS 등급에서와 똑같은 원칙이 적용됩니다 — 등급(A+) 자체가 목표가 아니라, 각 헤더가 실제로 무엇을 막는지 이해하고 켜는 것이 목적입니다. 점수만 보고 의미 없이 헤더를 욱여넣지는 마십시오.

한 장으로 정리하는 보안 헤더 체크리스트

복붙해서 작업 순서로 쓰십시오.

• 즉효 헤더 먼저 적용 — X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy로 불필요한 기능 차단
• HSTS 단계적 도입 — 짧은 max-age로 시작 → 점차 1년까지 확대 → 모든 하위 도메인 HTTPS 확인 후 includeSubDomains → 모든 준비 후에야 preload
• 모든 하위 도메인 HTTPS 지원 확인 — includeSubDomains를 켜기 전에 서브도메인 목록을 점검
• CSP는 관찰 모드부터 — Content-Security-Policy-Report-Only로 위반 수집 → 정당한 출처 추가 → CSP Evaluator로 우회 여부 점검 → 강제 전환
• 모든 헤더에 always — 오류 응답에도 헤더가 실리도록
• 중복 제거 — 서버/앱/프록시 중 한곳에서만 일관되게 관리
• 반드시 검증 — curl -sI로 실제 응답 확인, securityheaders.com·Mozilla Observatory로 보강

이 모든 항목을 관통하는 한 문장이 있습니다. "설정했다고 믿지 말고 측정하라." 보안 헤더는 켜는 것보다 켜졌는지 확인하는 것이 절반입니다.

자주 묻는 질문 (FAQ)

Q. 보안 헤더 중 무엇을 가장 먼저 켜야 하나요? 부작용이 거의 없고 한 줄로 끝나는 즉효 헤더부터 켜는 것이 좋습니다. 구체적으로 X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy(불필요 기능 차단) 네 가지입니다. 이들은 사이트를 깨뜨릴 위험이 낮아 바로 적용할 수 있습니다. HSTS는 단계적으로, CSP는 관찰 모드를 거쳐 가장 신중하게 도입하십시오.

Q. HSTS의 preload는 꼭 켜야 하나요? 필수는 아닙니다. preload는 가장 완벽한 보호를 주지만 동시에 가장 되돌리기 어려운 옵션입니다. 한 번 브라우저 사전 목록에 등록되면 제거 신청 후에도 오랫동안 효력이 남고, 그사이 인증서 문제나 HTTPS 미지원 하위 도메인이 생기면 사이트가 통째로 접속 불가 상태가 됩니다. 짧은 max-age로 검증 → 기간 확대 → includeSubDomains → 모든 준비 확인 후에만 preload를 신청하는 단계적 접근을 권합니다.

Q. CSP를 켰더니 사이트의 일부 기능이 동작하지 않습니다. 정당한 자원의 출처가 정책 허용 목록에서 빠졌기 때문일 가능성이 큽니다. 강제 모드(Content-Security-Policy)를 즉시 끄고, 대신 관찰 모드(Content-Security-Policy-Report-Only)로 전환해 어떤 자원이 차단되는지 위반 보고를 수집하십시오. 보고에 나온 정당한 출처를 정책에 추가해 더 이상 걸리는 것이 없을 때까지 다듬은 뒤, 다시 강제 모드로 전환하면 됩니다.

Q. 헤더를 설정했는데 어떤 응답에는 적용되고 어떤 응답에는 빠집니다. Nginx의 add_header에 always 옵션을 붙이지 않은 경우입니다. always가 없으면 정상(2xx·3xx) 응답에는 헤더가 실리지만 오류(4xx·5xx) 응답에는 빠질 수 있습니다. 모든 add_header 줄 끝에 always를 붙여 오류 페이지에도 헤더가 적용되게 하십시오. 또한 서버·애플리케이션·프록시 여러 곳에서 같은 헤더를 넣고 있지 않은지 확인해 중복·충돌을 제거하십시오.

Q. securityheaders.com에서 A 등급을 받으면 충분한가요? 등급은 빠진 헤더를 빠르게 파악하는 출발점일 뿐, 목표 자체는 아닙니다. 예를 들어 'unsafe-inline'을 허용하거나 인기 CDN을 통째로 화이트리스트에 넣은 CSP는 등급 도구에서는 통과해도 실제로는 XSS를 거의 막지 못합니다. 등급을 채운 뒤에는 CSP Evaluator로 정책의 우회 가능성을 점검하고, 각 헤더가 실제로 어떤 공격을 막는지 이해한 상태로 운영하는 것이 중요합니다.

원문 출처 및 더 알아보기

이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.

웹 보안 점검·긴급 대응이 필요하시면 DevTeam의 웹 긴급지원 또는 개발/보안 문의를 이용해 주세요.