보안 헤더 빠른 참조

사이트를 안전하게 유지하고 가장 중요한 세부정보를 빠르게 확인할 수 있는 헤더에 관해 자세히 알아보세요.

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas
Maud Nalpas
X GitHub

이 도움말에는 사용자를 보호하는 데 사용할 수 있는 가장 중요한 보안 헤더가 나와 있습니다. 확인할 수 있습니다 이를 사용하여 웹 기반 보안 기능을 이해하고, 웹사이트에 구현해 보세요. 필요할 때 참고할 수 있습니다.

민감한 사용자 데이터를 처리하는 웹사이트에 권장되는 보안 헤더는 다음과 같습니다.
콘텐츠 보안 정책 (CSP)
신뢰할 수 있는 유형
모든 웹사이트에 권장되는 보안 헤더:
X-Content-Type-Options
X프레임 옵션
교차 출처 리소스 정책 (CORP)
교차 출처 오프너 정책 (COOP)
HTTP Strict Transport Security (HSTS)
고급 기능이 있는 웹사이트의 보안 헤더:
교차 출처 리소스 공유 (CORS)
교차 출처 삽입 정책 (COEP)
웹에서 알려진 위협
보안 헤더를 살펴보기 전에 웹에서 알려진 위협에 대해 알아보기 보안 헤더를 사용해야 하는 이유를 설명합니다.

보안 헤더를 살펴보기 전에 웹에서 알려진 위협에 대해 알아보기 보안 헤더를 사용해야 하는 이유를 설명합니다.

인젝션 취약점으로부터 사이트 보호

주입 취약점은 Google 인프라 시스템에서 처리할 수 없는 동작에 영향을 미칠 수 있으며, 일반적으로 애플리케이션이 제어할 수 없습니다. 삽입으로 인해 발생하는 가장 일반적인 취약점 버그는 크로스 사이트이고 스크립트 (XSS)를 텍스트, 이미지, 오디오, 동영상 등 다양한 형태가 XSS, 저장된 XSS, DOM 기반 XSS 사용할 수 있습니다.

일반적으로 XSS 취약점으로 인해 공격자가 사용자 데이터에 완전히 액세스할 수 있습니다. 애플리케이션 및 동일한 웹에 호스팅된 기타 정보에 의해 처리됨 출처.

삽입에 대한 기존의 방어에는 자동 이스케이프의 일관적인 사용이 포함됩니다. HTML 템플릿 시스템을 통해 위험한 JavaScript 및 API를 호스팅하고 사용자 데이터를 적절히 처리하는 별도의 도메인에서 파일 업로드 및 사용자가 제어하는 HTML 정리

다른 웹사이트와 내 사이트 분리하기

웹의 개방성을 통해 웹사이트는 다음과 같은 방식으로 서로 상호작용할 수 있습니다. 애플리케이션의 보안 기대치를 위반할 수 있습니다. 여기에는 예상치 못한 경우도 포함됩니다. 인증 요청을 하거나 다른 애플리케이션의 데이터를 공격자가 애플리케이션 데이터를 수정하거나 읽을 수 있습니다.

웹 격리를 방해하는 일반적인 취약점은 다음과 같습니다. 클릭재킹, 크로스 사이트 위조 요청 (CSRF), 크로스 사이트 스크립트 포함 (XSSI) 및 크로스 사이트 유출.

포스트 스펙터 웹 개발이 유용한 자료 를 참조하세요.

강력한 웹사이트를 안전하게 구축

스펙터는 모든 데이터를 로드하여 동일한 브라우징 컨텍스트 그룹으로 복사됩니다. 동일 출처 정책에도 불구하고 브라우저의 기능 제한 특정 환경 이면의 취약점을 악용할 수 있는 악성 소프트웨어와 'cross-originorigin(교차 출처 분리)'을 참고하세요. 교차 출처 분리를 사용하면 SharedArrayBuffer와 같은 강력한 기능을 사용하세요.

사이트 트래픽 암호화

암호화 문제는 애플리케이션이 도청 공격자가 사용자와의 상호 작용에 대해 애플리케이션입니다.

HTTPS를 사용하지 않는 경우, 혼합 콘텐츠: Secure 속성 (또는 __Secure 접두사), 또는 느슨한 CORS 유효성 검사 로직을 참조하세요.

콘텐츠 보안 정책 (CSP)

교차 사이트 스크립팅 (XSS): 공격 웹사이트의 취약점으로 인해 악성 스크립트가 주입되어 실행됩니다

Content-Security-Policy는 다음을 통해 XSS 공격을 완화하는 추가 레이어를 제공합니다. 페이지에서 실행할 수 있는 스크립트를 제한합니다.

다음 방법 중 하나를 사용하여 엄격한 CSP를 사용 설정하는 것이 좋습니다.

  • 서버에서 HTML 페이지를 렌더링하는 경우 nonce 기반의 엄격한 CSP를 사용하세요.
  • HTML을 정적으로 제공하거나 캐시해야 하는 경우(예: 단일 페이지 애플리케이션의 경우 엄격한 해시 기반의 CSP를 사용하세요.

사용 예: nonce 기반 CSP

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
CSP 사용 방법

1. 엄격한 nonce 기반 CSP 사용 {: #nonce-based-csp}

서버에서 HTML 페이지를 렌더링하는 경우 nonce 기반의 엄격한 CSP를 사용하세요.

서버 측의 모든 요청에 대해 새 스크립트 nonce 값을 생성하고 다음 헤더를 포함합니다.

서버 구성 파일

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

HTML에서 스크립트를 로드하려면 모든 파일의 nonce 속성을 <script> 태그를 동일한 {RANDOM1} 문자열에 추가합니다.

index.html

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
  // Inline scripts can be used with the <code>nonce</code> attribute.
</script>

Google 포토는 좋은 nonce 기반의 엄격한 CSP입니다. 예로 들 수 있습니다 DevTools를 사용하여 사용 방법을 확인하세요.

2. 엄격한 해시 기반의 CSP 사용 {: #hash-based-csp}

HTML을 정적으로 제공하거나 캐시해야 하는 경우(예: 단일 페이지 애플리케이션을 빌드하려면 엄격한 해시 기반의 CSP를 사용하세요.

서버 구성 파일

Content-Security-Policy:
  script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

HTML에서는 해시 기반 태그를 적용하려면 스크립트를 삽입해야 합니다. 정책으로 인해 대부분의 브라우저는 스크립트와 동일합니다.

index.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

외부 스크립트를 로드하려면 '소스된 스크립트를 동적으로 로드'를 읽어보세요. 미달 옵션 B: 해시 기반 CSP 응답 헤더 섹션

CSP Evaluator는 CSP를 평가하는 동시에 nonce 기반의 엄격한 CSP 예를 사용합니다. DevTools를 사용하여 사용 방법을 확인하세요.

지원되는 브라우저

CSP 관련 기타 참고사항

자세히 알아보기

신뢰할 수 있는 유형

DOM 기반 XSS는 동적 코드를 지원하는 싱크로 악성 데이터가 전달되는 공격 (예: eval() 또는 .innerHTML)

신뢰할 수 있는 유형은 작성, 보안 검토, 유지보수를 위한 도구 제공 애플리케이션을 실행하는 데 사용할 수 있습니다. CSP를 통해 사용 설정할 수 있으며 위험한 웹 API가 해당 웹 API에서 특수 객체입니다.

이러한 객체를 만들려면 보안 규칙 (예: 이스케이프 또는 제거)이 일관되게 적용되는지 데이터를 DOM에 쓰기 전에 그러면 이러한 정책들이 포함되었습니다.

사용 예

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;
신뢰할 수 있는 유형 사용 방법

  1. 위험한 DOM 싱크에 신뢰할 수 있는 유형 적용 CSP 및 신뢰할 수 있는 유형 헤더: 

    Content-Security-Policy: require-trusted-types-for 'script'

    현재 'script'는 require-trusted-types-for 지시어.

    물론 신뢰할 수 있는 유형을 다른 CSP 지시문과 결합할 수 있습니다.

위의 nonce 기반 CSP를 신뢰할 수 있는 유형과 병합: 

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;




<aside class="note"><b>참고: </b> 추가적인 <code>trusted-types</code>를 설정하여 허용되는 신뢰할 수 있는 유형 정책 이름을 제한할 수 있습니다. 지시어 (예: <code>trusted-types myPolicy</code>) 그러나 필수 사항은 아닙니다.  </aside>


    
  
  1. 
    
    정책 정의
    
    
    정책:
    
   
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}

    
    
  
    2. 
  
  2. 
    
    정책 적용
    
    
    DOM에 데이터를 쓸 때 정책을 사용합니다.
    
   
    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;

    
    
    require-trusted-types-for 'script'에서 신뢰할 수 있는 유형을 사용하는 것은
      요구사항을 충족해야 합니다 위험한 DOM API를 문자열과 함께 사용하면
      오류가 발생했습니다.
    
  
    3. 



지원되는 브라우저



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


자세히 알아보기

X-Content-Type-Options

악성 HTML 문서가 도메인에서 제공되는 경우 (예: 사진 서비스에 업로드된 이미지에 유효한 HTML 마크업이 포함된 경우) 일부 브라우저의 경우 활성 문서로 처리하여 교차 사이트 스크립팅으로 이어지며 버그를 발견했습니다.

X-Content-Type-Options: nosniff는 브라우저에 에 설정된 MIME 유형 주어진 응답의 Content-Type 헤더가 올바릅니다. 이 헤더는 모든 리소스에 권장됩니다.

사용 예

X-Content-Type-Options: nosniff
X-Content-Type-Options 사용 방법

X-Content-Type-Options: nosniff는 서버를 올바른 Content-Type 헤더와 함께 연결합니다.

X-콘텐츠-유형-옵션: nosniff

문서 HTML과 함께 전송된 헤더 예

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

지원되는 브라우저

브라우저 지원

  • 64
  • 12
  • 50
  • 11

소스

자세히 알아보기

X프레임 옵션

악성 웹사이트에서 사이트를 iframe으로 삽입할 수 있는 경우 이로 인해 공격자가 의도치 않은 작업을 하도록 클릭재킹(clickjacking)의 예입니다. 또한 일부 케이스 스펙터 유형 악성 웹사이트는 삽입된 문서의 콘텐츠에 대해 학습할 수 있습니다.

X-Frame-Options는 브라우저가 렌더링하도록 허용해야 하는지 여부를 나타냅니다. <frame>, <iframe>, <embed> 또는 <object>의 페이지 모든 문서 이 헤더를 전송하여 광고 게재가 허용되는지 여부를 다른 문서에 삽입되어 있습니다.

사용 예

X-Frame-Options: DENY
X-Frame-Options 사용 방법

삽입하도록 설계되지 않은 모든 문서는 X-Frame-Options 헤더를 사용해야 합니다.

다음 구성이 iframe 로드에 미치는 영향을 이 페이지에서 시도해 볼 수 있습니다. 데모를 참고하세요. X-Frame-Options 변경 드롭다운 메뉴를 클릭하고 Reload the iframe 버튼을 클릭합니다.

내 웹사이트가 다른 웹사이트에 퍼지지 않도록 보호

다른 문서에 삽입되는 것을 거부합니다.

X프레임 옵션: 거부 
X-Frame-Options: DENY

교차 출처 웹사이트에서 내 웹사이트를 삽입하지 않도록 보호

출처가 동일한 문서에 의해서만 삽입되도록 허용

X-Frame-Options: SAMEORIGIN

지원되는 브라우저

브라우저 지원

  • 4
  • 12
  • 4
  • 4

소스

자세히 알아보기

교차 출처 리소스 정책 (CORP)

공격자가 다른 출처(예: 사이트)의 리소스를 삽입할 수 있습니다. 웹 기반 크로스 사이트(cross-site) 누수가 있는지 확인하세요.

Cross-Origin-Resource-Policy는 모든 웹 사이트를 지원합니다. 헤더는 다음 세 가지 값 중 하나를 사용합니다. same-origin, same-site, cross-origin 모든 리소스는 이 헤더를 전송하여 다른 웹사이트를 찾습니다.

사용 예

Cross-Origin-Resource-Policy: same-origin
CORP 사용 방법

모든 리소스를 다음 중 하나와 함께 제공하는 것이 좋습니다. 세 개의 헤더가 있습니다.

다음 구성이 클러스터의 리소스 로드에 어떤 영향을 미치는지 Cross-Origin-Embedder-Policy: require-corp 환경 이 데모를 참고하세요. 먼저 Cross-Origin-Resource-Policy 드롭다운 메뉴를 클릭하고 Reload the iframe 또는 이미지 새로고침 버튼을 눌러 효과를 확인합니다.

cross-origin에 리소스 로드 허용

CDN과 유사한 서비스는 리소스에 cross-origin를 적용하는 것이 좋습니다. (일반적으로 교차 출처 페이지에 의해 로드되기 때문) CORS를 통해 이를 사용할 수 있으며 이는 비슷한 효과를 발휘합니다.

교차 출처-리소스 정책: cross-origin 
Cross-Origin-Resource-Policy: cross-origin

same-origin에서 로드되도록 리소스 제한

same-origin는 로드하려는 리소스에만 적용되어야 합니다. 동일한 출처 페이지로 구성됩니다. 민감한 특성이 포함된 리소스에 이를 적용해야 합니다. 사용자에 대한 정보 또는 호출하려는 API의 응답 데이터를 가져올 수 있습니다

이 헤더가 있는 리소스는 여전히 예를 들어 새 브라우저 창에서 URL로 이동하면 됩니다. 교차 출처 리소스 정책은 다른 웹사이트에서 리소스를 삽입하지 못하도록 보호하기만 합니다.

교차 출처-리소스 정책: same-origin 
Cross-Origin-Resource-Policy: same-origin

same-site에서 로드되도록 리소스 제한

same-site는 위와 유사한 리소스에 적용하는 것이 좋습니다. 사이트의 다른 하위 도메인에 의해 로드되도록 하기 위한 것입니다.

교차 출처-리소스 정책: 동일 사이트 
Cross-Origin-Resource-Policy: same-site

지원되는 브라우저

브라우저 지원

  • 73
  • 79
  • 74
  • 12

소스

자세히 알아보기

교차 출처 오프너 정책 (COOP)

공격자의 웹사이트가 팝업 창에서 다른 사이트를 열어서 웹 기반 크로스 사이트(cross-site) 누수가 있는지 확인하세요. 경우에 따라 이렇게 하면 익스플로잇을 기반으로 한 부채널 공격을 스펙터

Cross-Origin-Opener-Policy 헤더를 사용하면 문서를 격리하는 방법을 사용할 수 있습니다. window.open() 또는 rel="noopener" 없이 target="_blank". 따라서 모든 교차 출처 오프너는 문서에 대한 참조가 없으며 상호작용할 수 없습니다. 사용할 수 있습니다.

사용 예

Cross-Origin-Opener-Policy: same-origin-allow-popups
COOP 사용 방법

다음 구성이 원격 네트워크(ISP)와의 통신에 어떤 영향을 미치는지 이 데모의 교차 출처 팝업 창입니다. 두 문서 모두에 대해 Cross-Origin-Opener-Policy 드롭다운 메뉴를 변경합니다. 팝업 창에서 팝업 열기 버튼을 클릭한 다음 postMessage를 확인하여 메시지가 실제로 전송되는지 확인합니다.

교차 출처 창에서 문서 격리

same-origin를 설정하면 문서가 교차 출처에서 격리됩니다. 문서 창을 엽니다.

Cross-Origin-Opener-Policy: same-origin 
Cross-Origin-Opener-Policy: same-origin

교차 출처 창에서 문서를 격리하되 팝업은 허용

same-origin-allow-popups를 설정하면 문서에서 same-origin 또는 same-origin-allow-popups 즉, same-origin-allow-popups 앱은 여전히 팝업 창으로 열릴 때 문서가 참조되지 않도록 보호하지만 자체 팝업과 통신할 수 있도록 합니다.

Cross-Origin-Opener-Policy: same-origin-allow-popups 
Cross-Origin-Opener-Policy: same-origin-allow-popups

교차 출처 창에서 문서를 참조하도록 허용

unsafe-none가 기본값이지만 이 값을 명시적으로 나타낼 수 있습니다. 교차 출처 창에서 문서를 열고 상호 액세스를 유지할 수 있습니다.

교차 출처 Opener 정책: 안전하지 않음-없음 
Cross-Origin-Opener-Policy: unsafe-none

COOP와 호환되지 않는 보고서 패턴

COOP가 Reporting API입니다.

Cross-Origin-Opener-Policy: same-origin; report-to="coop"

COOP는 또한 보고서 전용 모드를 지원하므로 실제로 교차 출처 문서 간의 통신을 차단합니다.

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

지원되는 브라우저

브라우저 지원

  • 83
  • 83
  • 79
  • 15.2

소스

자세히 알아보기

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

이 도움말의 다른 항목과 달리 교차 출처 리소스 공유 (CORS)는 헤더에 있지만 교차 출처 리소스입니다

기본적으로 브라우저에서는 웹페이지에서 교차 출처 리소스에 액세스하는 것을 방지합니다. 예를 들어 교차 출처 이미지가 웹페이지에 표시되더라도 로드됨 시각적으로 페이지의 JavaScript는 이미지 데이터에 액세스할 수 없습니다. 리소스 제공업체는 제한을 완화하고 다른 웹사이트에서 읽을 수 있도록 허용할 수 있습니다. 리소스 사용을 제한할 수 있습니다

사용 예

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
CORS 사용 방법

CORS를 구성하는 방법을 알아보기 전에 구별하는 데 사용됩니다. 요청 세부정보에 따라 단순 요청 또는 실행 전 요청으로 분류됩니다.

단순 요청의 기준:

  • 메서드는 GET, HEAD 또는 POST입니다.
  • 커스텀 헤더에는 Accept, Accept-Language, Content-Language, Content-Type
  • Content-Type는 application/x-www-form-urlencoded입니다. multipart/form-data 또는 text/plain입니다.

나머지는 모두 프리플라이트 요청으로 분류됩니다. 자세한 내용은 교차 출처 리소스 공유 (CORS) - HTTP | MDN

간단한 요청

요청이 단순 요청 기준을 충족하면 브라우저에서 요청을 나타내는 Origin 헤더가 있는 교차 출처 요청 출처입니다.

요청 헤더 예시

Get / HTTP/1.1
Origin: https://example.com

응답 헤더 예시

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com는 https://example.com는 응답의 내용에 액세스할 수 있습니다. 리소스 의미 이 헤더를 *로 설정할 수 있습니다. 이 경우 브라우저는 별도의 설정 없이 사용자 인증 정보를 제공합니다.
  • Access-Control-Allow-Credentials: true는 사용자 인증 정보 (쿠키)를 통해 리소스를 로드할 수 있습니다. 그렇지 않으면 요청한 출처가 Access-Control-Allow-Origin 헤더에 있습니다.

간단한 요청이 단일 가상 머신의 리소스 로드에 Cross-Origin-Embedder-Policy: require-corp 환경 이 데모를 참고하세요. 그런 다음 교차 출처 리소스 공유 체크박스 선택 및 이미지 새로고침 클릭 버튼을 클릭하여 효과를 확인합니다.

프리플라이트된 요청

실행 전 요청 전에 OPTIONS 요청이 와서 후속 요청을 보낼 수 있습니다.

요청 헤더 예시

OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
  • Access-Control-Request-Method: POST에서는 다음 요청을 허용합니다. POST 메서드 사용
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type를 사용하면 X-PINGOTHER 및 Content-Type HTTP 헤더를 설정하도록 반환합니다.

응답 헤더 예시

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
  • Access-Control-Allow-Methods: POST, GET, OPTIONS는 요청은 POST, GET, OPTIONS 메서드로 실행할 수 있습니다.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type는 후속 조치를 나타냅니다. 요청에는 X-PINGOTHER 및 Content-Type 헤더가 포함될 수 있습니다.
  • Access-Control-Max-Age: 86400는 프리플라이트 처리된 결과를 나타냅니다. 요청은 86,400초 동안 캐시될 수 있습니다.

지원되는 브라우저

브라우저 지원

  • 4
  • 12
  • 3.5
  • 4

소스

자세히 알아보기

교차 출처 삽입 정책 (COEP)

스펙터 기반의 능력을 축소하기 위해 공격을 교차 출처 리소스 도용(SharedArrayBuffer 또는 performance.measureUserAgentSpecificMemory()는 기본적으로 사용 중지되어 있습니다.

Cross-Origin-Embedder-Policy: require-corp는 문서 및 작업자가 교차 출처 리소스 로드(예: 이미지, 스크립트, 스타일시트, iframe 및 기타 리소스가 명시적으로 CORS를 통해 로드되도록 선택하지 않는 한 또는 CORP 헤더로 구성됩니다. COEP를 Cross-Origin-Opener-Policy와 함께 사용할 수 있습니다. 문서를 교차 출처 분리로 선택하세요.

사용 설정하려면 Cross-Origin-Embedder-Policy: require-corp을(를) 사용하세요. 문서의 교차 출처 분리

사용 예

Cross-Origin-Embedder-Policy: require-corp
COEP 사용 방법

사용 예

COEP는 단일 값 require-corp를 사용합니다. 이 헤더를 전송하면 를 통해 선택하지 않는 리소스의 로드를 차단하도록 CORS 또는 CORP.

COEP 작동 방식

다음 구성이 리소스 로드에 어떤 영향을 미치는지 데모를 참고하세요. 먼저 Cross-Origin-Embedder-Policy 드롭다운 메뉴, Cross-Origin-Resource-Policy 드롭다운 메뉴, Report Only 체크박스 등 리소스 로드에 미치는 영향을 확인할 수 있습니다. 또한 보고 엔드포인트 데모를 사용하여 차단된 리소스가 보고되었습니다.

교차 출처 분리 사용 설정

다음 항목을 전송하여 교차 출처 분리 사용 설정 Cross-Origin-Embedder-Policy: require-corp님과 함께 Cross-Origin-Opener-Policy: same-origin입니다. 

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

COEP와 호환되지 않는 보고서 리소스

보고 기능을 사용하여 COEP로 인해 차단된 리소스에 대한 보고서를 받을 수 있습니다. API에 액세스할 수 있습니다.

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP는 또한 보고서 전용 모드를 지원하므로 실제로 리소스 로드를 차단합니다

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

지원되는 브라우저

브라우저 지원

  • 83
  • 83
  • 79
  • 15.2

소스

자세히 알아보기

HSTS (HTTP Strict Transport Security)

일반 HTTP 연결을 통한 통신은 암호화되지 않으므로 네트워크 수준의 도청자가 액세스할 수 있는 전송된 데이터

Strict-Transport-Security 헤더는 로드해서는 안 된다고 브라우저에 알립니다. HTTP를 사용하여 사이트에서 HTTPS를 대신 사용할 수 있습니다. 설정이 완료되면 브라우저에서 일정 기간 동안 리디렉션 없이 도메인에 액세스하기 위한 HTTP 대신 HTTPS 헤더에서 정의합니다.

사용 예

Strict-Transport-Security: max-age=31536000
HSTS 사용 방법

HTTP에서 HTTPS로 전환하는 모든 웹사이트는 HTTP 요청이 수신될 때의 Strict-Transport-Security 헤더입니다. 

Strict-Transport-Security: max-age=31536000

지원되는 브라우저

브라우저 지원

  • 4
  • 12
  • 4
  • 7

소스

자세히 알아보기

추가 자료