웹사이트 보안 헤더 이해: 현대 웹 애플리케이션을 위한 필수 보호

EdgeOneDev-Dev Team
10 분 읽기
May 29, 2025

website security headers.png

웹사이트 보안 헤더는 현대 웹 개발의 필수 구성 요소로, 다양한 사이버 위협으로부터 웹사이트를 보호하는 데 중요한 역할을 합니다. 이러한 헤더는 HTTP 프로토콜의 일부이며, 브라우저가 데이터와 웹사이트와의 상호작용을 처리하는 방법을 지정하여 추가적인 보안 계층을 제공합니다. 이 기사는 보안 헤더의 중요성, 사용 가능한 다양한 유형 및 구현을 위한 모범 사례에 대해 설명할 것입니다.

HTTP 보안 헤더란?

HTTP 헤더는 브라우저와 서버 간의 요청-응답 통신의 중요한 구성 요소입니다. 사용자가 웹사이트로 이동하면, 그들의 브라우저는 서버에 HTTP 요청을 보냅니다. 서버는 요청된 콘텐츠와 함께 브라우저가 이 콘텐츠를 처리하는 방법에 대한 지침을 제공하는 HTTP 헤더를 응답합니다.

보안 헤더는 특정적으로 브라우저에게 웹사이트를 렌더링하고 상호작용하는 동안 시행해야 하는 보안 정책에 대해 알려줍니다. 이들은 동일 출처 정책 및 기타 보안 경계를 따르는 브라우저의 보안 모델 내에서 작동합니다. 특정 보안 헤더를 추가함으로써 웹사이트 소유자는 이러한 네이티브 브라우저 보호를 더욱 강화할 수 있습니다.

보안 헤더는 다음과 같은 다양한 유형의 공격을 방지할 수 있습니다:

  • 크로스 사이트 스크립팅 (XSS)
  • 클릭재킹
  • MIME 타입 스니핑
  • 중간자 공격
  • 데이터 주입 공격
  • 크로스 사이트 요청 위조 (CSRF)

주요 보안 헤더 설명

콘텐츠 보안 정책 (CSP)

콘텐츠 보안 정책은 오늘날 가장 강력한 보안 헤더 중 하나로 간주됩니다. 이는 화이트리스트로 작동하며, 브라우저가 특정 페이지에 대해 로드할 수 있는 리소스를 지정합니다.

  • 목적 및 기능: CSP는 어떤 스크립트, 스타일, 이미지 및 기타 리소스가 페이지에서 실행될 수 있는지를 제어하여 XSS 위험을 완화합니다. 신뢰할 수 있는 출처를 지정함으로써, CSP는 악성 스크립트 주입 및 실행을 방지합니다.
  • 주요 지시문 및 그 효과:
    • default-src: 다른 리소스 유형에 대한 기본값으로 작용
    • script-src: 어떤 스크립트가 실행될 수 있는지를 제어
    • style-src: 스타일 시트의 허용 가능한 출처를 정의
    • img-src: 이미지 출처 제한
    • connect-src: 페이지가 연결할 수 있는 출처 제한 (XHR, WebSockets 등)
  • 구현 예:
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src *; style-src 'self' 'unsafe-inline';

이 정책은 스크립트를 원본 서버와 trusted.cdn.com에서만 허용하고, 스타일은 인라인 스타일이 허용된 원본에서, 이미지는 모든 출처에서 허용합니다.

HTTP 엄격 전송 보안 (HSTS)

HSTS는 안전한 연결을 강제하여 브라우저가 도메인과의 모든 향후 통신에 HTTPS를 사용하도록 요구합니다.

  • 안전한 연결 강제: 브라우저가 웹사이트에서 HSTS 헤더를 수신하면, 모든 HTTP 요청을 HTTPS로 자동 변환하여 잠재적인 다운그레이드 공격을 방지합니다.
  • 구현 모범 사례:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age 지시문은 브라우저가 얼마나 오랫동안 (초 단위) HTTPS를 독점적으로 사용해야 하는지를 지정하며, includeSubDomains는 이 정책을 모든 하위 도메인에 적용하고, preload는 도메인을 브라우저의 내장 HSTS 프리로드 목록에 포함시키도록 제안합니다.

X-Content-Type-Options

이 간단하지만 효과적인 헤더는 브라우저가 MIME 스니핑을 방지합니다. MIME 스니핑은 브라우저가 서버가 선언한 내용과 상관없이 파일의 콘텐츠 유형을 결정하려고 시도하는 기술입니다.

  • 구현 예:
X-Content-Type-Options: nosniff

이 헤더를 설정함으로써, 브라우저가 선언된 콘텐츠 유형을 존중하게 되어 악성 파일이 무해한 콘텐츠 유형으로 가장하는 특정 유형의 공격을 방지합니다.

X-Frame-Options

X-Frame-Options 헤더는 브라우저가 페이지를 <frame>, <iframe>, <embed> 또는 <object>에서 렌더링할 수 있는지 여부를 제어하여 클릭재킹 공격으로부터 보호합니다.

  • 구성 옵션:
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://trusted-site.com/

DENY는 어떤 도메인이든 콘텐츠를 프레임할 수 없도록 하고, SAMEORIGIN는 동일 출처의 페이지만 콘텐츠를 프레임할 수 있도록 허용하며, ALLOW-FROM은 특정 사이트가 당신의 콘텐츠를 프레임하도록 허용합니다 (다만 이 옵션은 CSP frame-ancestors로 대체되었습니다).

X-XSS-Protection

비록 현대 브라우저들이 더 정교한 XSS 보호 기능을 구현하고 CSP가 더 강력한 제어를 제공하지만, 이 헤더는 여전히 구형 브라우저 사용자에게 추가 보호를 제공할 수 있습니다.

X-XSS-Protection: 1; mode=block

값 1은 브라우저의 내장 XSS 필터를 활성화하며, mode=block은 공격이 감지되면 페이지가 렌더링되지 않도록 합니다.

참조자 정책

이 헤더는 요청과 함께 포함되어야 할 참조자 정보의 양을 제어하여 사용자 개인 정보를 보호하고 정보 유출을 방지합니다.

  • 사용 가능한 정책 옵션:
Referrer-Policy: no-referrer
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: same-origin

no-referrer 정책은 Referer 헤더를 완전히 생략하고, strict-origin-when-cross-origin은 동일 출처 요청 시 origin, path 및 query string을 보내지만, 프로토콜 보안 수준이 동일할 때는 origin만 보내고 보안을 다운그레이드할 때는 참조자를 보내지 않습니다. same-origin은 동일 출처 요청에 대해서만 전체 참조자를 보냅니다.

권한 정책

기능 정책(Feature-Policy)로 알려졌던 이 헤더는 개발자가 웹 애플리케이션 내에서 특정 브라우저 기능 및 API를 명시적으로 활성화하거나 비활성화할 수 있게 해줍니다.

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

이 예시는 페이지 및 모든 iframe에 대해 지리 위치, 카메라 및 마이크 API를 비활성화합니다.

구현 전략

서버 구성 예

  • Apache:
<IfModule mod_headers.c>
    Header always set Content-Security-Policy "default-src 'self';"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
  • Nginx:
server {
    listen 443 ssl;
    # SSL configuration here
    
    add_header Content-Security-Policy "default-src 'self';" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}
  • Express.js:
const helmet = require('helmet');
const express = require('express');
const app = express();

// 여러 보안 헤더를 자동으로 설정하기 위해 헬멧 사용
app.use(helmet());

// 또는 특정 헤더를 사용자 정의
app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'", 'trusted-cdn.com']
  }
}));

CMS 구현

WordPress와 같은 인기 있는 콘텐츠 관리 시스템에서는 "Security Headers"와 같은 플러그인을 통해 보안 헤더를 구현하거나 .htaccess 파일이나 테마 함수에 사용자 정의 코드를 추가하여 구현할 수 있습니다. 일부 호스팅 제공업체는 제어판을 통해 보안 헤더 구성을 제공하기도 합니다.

테스트 및 검증

구현 후에는 다음과 같은 도구를 사용하여 보안 헤더를 검증하는 것이 중요합니다:

  • 모질라 관측소
  • SecurityHeaders.com
  • Chrome DevTools (네트워크 탭)
  • 온라인 CSP 검증기

고급 헤더 기술

하위 리소스 무결성 (SRI)

SRI는 브라우저가 가져오는 리소스가 예상치 못한 조작 없이 전달되었는지를 검증할 수 있도록 합니다. 스크립트 및 링크 태그에 무결성 속성을 추가함으로써, 예상된 파일만 실행되도록 보장할 수 있습니다:

<script src="https://cdn.example.com/script.js" 
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" 
        crossorigin="anonymous"></script>

인증서 투명성을 위한 Expect-CT

Expect-CT: max-age=86400, enforce, report-uri="https://example.com/report"

이 헤더는 인증서 투명성 요구 사항을 시행하여, 도메인에 대해 잘못 발급된 SSL 인증서를 감지하고 방지하는 데 도움을 줍니다.

교차 출처 리소스 공유 (CORS) 헤더

CORS 헤더는 한 출처에서 실행되는 웹 애플리케이션이 다른 출처의 리소스를 요청하는 방법을 제어합니다:

Access-Control-Allow-Origin: https://trusted-site.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

사이트 데이터 지우기

이 강력한 헤더는 웹사이트와 관련된 탐색 데이터를 (쿠키, 저장소, 캐시) 지웁니다:

Clear-Site-Data: "cache", "cookies", "storage"

로그아웃 기능이나 개인정보 보호 제어에 특히 유용합니다.

일반적인 도전 과제 및 해결책

보안과 기능의 균형 맞추기

강력한 보안 헤더를 구현하는 데 있어 가장 큰 도전 중 하나는 웹사이트 기능을 유지하는 것입니다. CSP와 같은 엄격한 정책은 인라인 JavaScript, 서드파티 위젯 또는 분석 기능을 중단시킬 수 있습니다. 해결책은 다음과 같습니다:

  • CSP를 점진적으로 구현하며, 보고 전용 모드로 시작
  • 이동할 수 없는 인라인 스크립트에 대한 nonce 또는 해시 사용
  • 모든 콘텐츠 출처 및 필요한 기능을 철저히 감사

서드파티 콘텐츠 통합

현대 웹사이트는 분석부터 소셜 미디어 위젯까지 여러 서드파티 서비스에 의존합니다. 이러한 서비스를 사용하면서 보안을 유지하기 위해:

  • 필요한 모든 외부 도메인의 종합 목록 유지
  • 서드파티 콘텐츠의 소스 도메인 변경 사항을 정기적으로 감사
  • 가능한 경우 서드파티 스크립트에 하위 리소스 무결성 사용 고려
  • CSP 보고를 사용하여 차단된 리소스를 식별하고 화이트리스트에 추가

구형 브라우저 지원

대부분의 현대 브라우저가 보안 헤더를 지원하지만, 구형 브라우저를 수용해야 할 수도 있습니다:

  • 구형 브라우저에 대한 우아한 저하 구현
  • 여러 브라우저 버전에서 테스트
  • 적절한 경우 폴리필 사용
  • 매우 오래되고 불안전한 브라우저 지원의 위험 고려

효과 및 준수 측정

보안 헤더 스캔 도구

정기적인 스캔은 헤더가 효과적으로 유지되도록 돕습니다:

  • OWASP ZAP (Zed Attack Proxy)
  • Qualys SSL Labs 서버 테스트
  • Lighthouse 보안 감사

준수 요구 사항

보안 헤더는 준수 프레임워크와 점점 더 관련성이 높아지고 있습니다:

  • PCI DSS의 안전한 코딩 관행 요구 사항
  • GDPR의 데이터 보호 고려사항
  • 의료 웹사이트의 HIPAA 보안 요구 사항

보안 헤더의 미래 동향

보안 헤더의 환경은 다음과 같이 진화하고 있습니다:

  • 개인정보 보호 강화 헤더에 대한 더 큰 강조
  • 보다 포괄적인 솔루션을 위해 오래된 헤더의 폐기
  • 브라우저 공급업체의 보다 엄격한 기본 보안 정책 구현
  • Origin Policy와 같은 새로운 표준과의 통합

보안 헤더 구현 체크리스트

HTTP 보안 헤더를 구현하는 것은 웹사이트 소유자에게 가장 비용 효율적인 보안 조치 중 하나를 나타냅니다. 이러한 헤더의 적절한 구성은 일반 웹 취약점에 대한 공격 표면을 크게 줄이고 보안 모범 사례에 대한 약속을 보여줍니다.

  1. 전체 사이트에 걸쳐 HTTPS 배포
  2. 안전한 연결을 강제하기 위해 HSTS 구현
  3. 콘텐츠 보안 정책(CSP) 구성 (보고 전용 모드로 시작)
  4. MIME 스니핑 방지를 위해 X-Content-Type-Options 추가
  5. 정보 유출을 방지하기 위해 Referrer-Policy 구현
  6. 클릭재킹 방지를 위해 X-Frame-Options 구성
  7. 기능 사용을 제어하기 위해 Permissions-Policy 추가
  8. 보안 스캐너를 사용하여 구현 테스트
  9. 잠재적인 문제를 위해 CSP 보고 모니터링
  10. 정기적으로 보안 헤더 검토 및 업데이트

이러한 보안 헤더에 대한 포괄적인 접근 방식을 따르면 조직은 상대적으로 최소한의 노력과 비용으로 웹 보안 태세를 크게 강화할 수 있으며, 일반적인 공격으로부터 사용자와 자신의 디지털 자산을 보호할 수 있습니다.

결론

텐센트 EdgeOne는 텐센트 엣지 노드를 기반으로 한 가속 및 보안 솔루션을 제공하며, WAF 및 Anti-DDoS와 같은 보안 보호 서비스를 제공합니다. 노드는 다양한 레이어 3/4/7 공격 요청을 식별하고 차단하며, DDoS 공격 트래픽을 정화하고, 스마트 AI 엔진 및 봇 정책 엔진을 사용하여 웹, 봇 및 CC 공격의 행동을 분석하고 공격 차단 정책을 업데이트합니다. 이를 통해 악의적인 요청이 원본 서버에 도달하지 않도록 방지하고 비즈니스에 대한 원활하고 안정적인 액세스를 보장합니다. 가입하세요 그리고 무료 체험을 시작하세요!