작은 사이트를 위한 HTTP 보안 헤더 시작하기
CloudPlare 편집 노트 · 최초 작성 2026-05-26 · 최종 검토 2026-06-10 · 8분 읽기
보안 헤더는 큰 서비스만의 설정이 아닙니다. 정적 콘텐츠 사이트라도 몇 가지 헤더만 추가하면 스크립트 삽입이나 클릭재킹 같은 흔한 위험을 줄일 수 있습니다. 다만 한 번에 모두 적용하면 사이트가 깨질 수 있어 순서가 중요합니다.
정적 사이트도 헤더로 스스로를 보호한다
로그인이나 결제가 없는 정적 사이트는 보안과 거리가 멀어 보이지만, 외부 스크립트가 삽입되거나 다른 사이트의 iframe에 그대로 표시되는 문제는 어떤 사이트에도 일어날 수 있습니다. HTTP 응답 헤더 몇 가지만 추가해도 이런 시나리오의 위험을 크게 줄일 수 있습니다.
Content-Security-Policy는 신고 모드로 시작한다
CSP(Content-Security-Policy)는 페이지가 어떤 출처의 스크립트, 스타일, 이미지를 불러올 수 있는지 제한합니다. 처음부터 차단 모드로 적용하면 분석 스크립트나 폰트 CDN처럼 실제로 필요한 리소스까지 막혀 화면이 깨질 수 있습니다. Content-Security-Policy-Report-Only 헤더로 먼저 어떤 리소스가 정책에 걸리는지 확인한 뒤, 허용 목록을 정리하고 차단 모드로 전환하는 순서가 안전합니다.
Referrer-Policy로 전달되는 정보를 줄인다
방문자가 외부 링크를 클릭해 다른 사이트로 이동할 때, 브라우저는 기본적으로 이전 페이지의 주소를 함께 전달합니다. Referrer-Policy 헤더로 이 정보를 얼마나 전달할지 조절할 수 있습니다. strict-origin-when-cross-origin처럼 도메인 정보까지만 전달하도록 설정하면, 글 제목이나 검색어가 포함된 URL이 외부에 그대로 노출되는 것을 줄일 수 있습니다.
Permissions-Policy로 불필요한 권한을 차단한다
카메라, 마이크, 위치 정보처럼 브라우저가 제공하는 기능 중 콘텐츠 사이트에서 쓰지 않는 권한은 명시적으로 차단할 수 있습니다. Permissions-Policy 헤더로 사용하지 않는 기능을 비활성화해두면, 페이지에 삽입된 외부 iframe이나 스크립트가 해당 권한을 요청할 수 있는 경로 자체를 줄일 수 있습니다.
헤더는 적용 후 실제로 확인한다
헤더를 설정 파일에 추가했다고 끝나는 것이 아닙니다. 배포 후 브라우저 개발자 도구의 네트워크 탭에서 실제 응답 헤더를 열어, 의도한 값이 실제 도메인에도 적용됐는지 확인해야 합니다. CDN이나 호스팅 플랫폼이 일부 헤더를 자체적으로 추가하거나 덮어쓰는 경우도 있으므로, 로컬 설정과 실제 배포 결과를 함께 봐야 합니다.
운영 체크리스트
- CSP를 Report-Only 모드로 먼저 적용해 영향을 확인했다.
- 실제로 필요한 스크립트와 폰트 출처를 허용 목록에 정리했다.
- Referrer-Policy 값을 설정해 외부로 전달되는 정보를 줄였다.
- 사용하지 않는 브라우저 기능을 Permissions-Policy로 제한했다.
- 배포 후 실제 도메인의 응답 헤더를 개발자 도구로 확인했다.
- 헤더 변경으로 정상 동작하던 스크립트나 폰트가 깨지지 않았다.
확인한 공식 자료
아래 자료를 바탕으로 운영 관점의 설명을 덧붙였습니다. 세부 동작은 서비스와 배포 환경에 따라 달라질 수 있습니다.