이 페이지는 Cloud Translation API를 통해 번역되었습니다.

보안 헤더 빠른 참조

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

키타무라 에이지

아르투르 얀크

Maud Nalpas

이 문서에는 웹사이트를 보호하는 데 사용할 수 있는 가장 중요한 보안 헤더가 나와 있습니다. 웹 기반 보안 기능을 이해하고, 웹사이트에서 기능을 구현하는 방법을 알아보고, 알림이 필요할 때 참고 자료로 활용할 수 있습니다.

민감한 사용자 데이터를 처리하는 웹사이트에 권장되는 보안 헤더:: 콘텐츠 보안 정책 (CSP); 신뢰할 수 있는 유형
모든 웹사이트에 권장되는 보안 헤더:: X-Content-Type-Options; X-Frame-Options; 교차 출처 리소스 정책 (CORP); 교차 출처 오프너 정책 (COOP); HTTP Strict Transport Security (HSTS)
고급 기능이 있는 웹사이트용 보안 헤더:: 교차 출처 리소스 공유 (CORS); 교차 출처 삽입 정책 (COEP)

웹에서 알려진 위협

보안 헤더를 살펴보기 전에 웹에 알려진 위협과 이 보안 헤더를 사용해야 하는 이유에 대해 알아보세요.

보안 헤더를 알아보기 전에 웹의 알려진 위협과 이 보안 헤더를 사용해야 하는 이유에 대해 알아보세요.

삽입 취약점으로부터 사이트 보호

삽입 취약점은 애플리케이션에서 처리하는 신뢰할 수 없는 데이터가 데이터 동작에 영향을 미칠 수 있고 일반적으로 공격자가 제어하는 스크립트의 실행으로 이어질 수 있을 때 발생합니다. 삽입 버그에 의해 발생하는 가장 일반적인 취약점은 반사된 XSS, 저장된 XSS, DOM 기반 XSS, 기타 변형을 비롯한 다양한 형태의 교차 사이트 스크립팅 (XSS)입니다.

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

삽입에 대한 기존의 방어 수단에는 HTML 템플릿 시스템 자동 이스케이프 처리의 일관된 사용, 위험한 JavaScript API 사용 방지, 별도의 도메인에서 파일 업로드를 호스팅하고 사용자가 제어하는 HTML 정리를 통한 사용자 데이터 올바른 처리 등이 포함됩니다.

콘텐츠 보안 정책 (CSP)을 사용하여 애플리케이션에서 실행할 수 있는 스크립트를 제어하여 삽입 위험을 줄이세요.
신뢰할 수 있는 유형을 사용하여 위험한 JavaScript API로 전달된 데이터 정리를 시행합니다.
X-Content-Type-Options를 사용하면 브라우저에서 웹사이트 리소스의 MIME 유형을 잘못 해석하여 스크립트가 실행될 수 있습니다.

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

웹의 개방성으로 인해 웹사이트는 애플리케이션의 보안 기대치를 위반하는 방식으로 서로 상호작용할 수 있습니다. 여기에는 예기치 않게 인증된 요청을 하거나 다른 애플리케이션의 데이터를 공격자의 문서에 삽입하여 공격자가 애플리케이션 데이터를 수정하거나 읽을 수 있게 하는 행위가 포함됩니다.

웹 격리를 약화시키는 일반적인 취약점으로는 클릭재킹, 크로스 사이트 요청 위조 (CSRF), 크로스 사이트 스크립트 포함 (XSSI), 다양한 크로스 사이트 유출 등이 있습니다.

X-Frame-Options를 사용하여 악성 웹사이트에서 문서를 삽입하지 못하게 합니다.
교차 출처 리소스 정책 (CORP)을 사용하여 웹사이트의 리소스가 교차 출처 웹사이트에 포함되지 않도록 하세요.
교차 출처 오프너 정책 (COOP)을 사용하여 악성 웹사이트의 상호작용으로부터 웹사이트 창을 보호하세요.
교차 출처 리소스 공유 (CORS)를 사용하여 교차 출처 문서에서 웹사이트 리소스에 대한 액세스를 제어합니다.

이러한 헤더에 관심이 있다면 Post-Spectre Web Development를 읽어 보세요.

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

스펙터는 동일 출처 정책에도 불구하고 읽을 수 있는 동일한 브라우징 컨텍스트 그룹에 로드된 모든 데이터를 배치합니다. 브라우저는 '교차 출처 격리'라고 하는 특수한 환경의 취약점을 악용할 수 있는 기능을 제한합니다. 교차 출처 격리를 사용하면 SharedArrayBuffer와 같은 강력한 기능을 사용할 수 있습니다.

교차 출처 삽입 정책 (COEP)과 COOP를 함께 사용하여 교차 출처 격리를 사용 설정합니다.

사이트로 유입되는 트래픽 암호화

암호화 문제는 애플리케이션이 전송 중 데이터를 완전히 암호화하지 못할 때 나타나며, 이로 인해 도청 공격자가 사용자와 애플리케이션의 상호작용에 대해 알 수 있습니다.

HTTPS를 사용하지 않거나 혼합 콘텐츠를 사용하지 않거나 Secure 속성(또는 __Secure 접두사) 없이 쿠키를 설정하거나 CORS 유효성 검사 로직이 느슨한 경우에는 암호화가 불충분할 수 있습니다.

HTTP Strict Transport Security (HSTS)를 사용하여 HTTPS를 통해 콘텐츠를 일관되게 제공하세요.

콘텐츠 보안 정책 (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에서 스크립트를 로드하려면 모든 <script> 태그의 nonce 속성을 동일한 {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를 사용해 사용 방식을 확인하세요.

지원되는 브라우저

* https:는 Safari를 대체하며 unsafe-inline는 매우 오래된 브라우저 버전의 대체입니다. https: 및 unsafe-inline는 strict-dynamic을 지원하는 브라우저에서 무시되므로 정책 안전성을 떨어뜨리지 않습니다. Safari 및 이전 브라우저 지원을 위한 대체 기능 추가하기에서 자세히 알아보세요. * Safari는 아직 strict-dynamic를 지원하지 않습니다. 하지만 위 예와 같이 엄격한 CSP가 모든 사용자에게 허용 목록 CSP보다 안전하며 CSP를 전혀 사용하지 않는 것보다 훨씬 안전합니다. Safari에서도 엄격한 CSP가 일부 유형의 XSS 공격으로부터 사이트를 보호합니다. CSP가 있으면 안전하지 않은 특정 패턴이 허용되지 않기 때문입니다.

기타 CSP 관련 참고사항

frame-ancestors 지시어는 클릭재킹으로부터 사이트를 보호합니다. 클릭재킹은 신뢰할 수 없는 사이트에 내 사이트 삽입을 허용하는 경우 발생할 수 있는 위험입니다. 더 간단한 솔루션을 선호하는 경우 X-Frame-Options를 사용하여 로드를 차단할 수 있지만 frame-ancestors는 특정 출처만 삽입자로 허용하는 고급 구성을 제공합니다.
사이트의 모든 리소스가 HTTPS를 통해 로드되도록 하기 위해 CSP를 사용했을 수 있습니다. 따라서 관련성이 낮아졌습니다. 오늘날 대부분의 브라우저에서 혼합 콘텐츠를 차단합니다.
CSP를 보고서 전용 모드로 설정할 수도 있습니다.
CSP를 헤더 서버 측으로 설정할 수 없는 경우 메타 태그로 설정할 수도 있습니다. 메타 태그에는 보고서 전용 모드를 사용할 수 없습니다 (변경될 수 있음).

자세히 알아보기

신뢰할 수 있는 유형

DOM 기반 XSS는 eval() 또는 .innerHTML와 같은 동적 코드 실행을 지원하는 싱크로 악성 데이터를 전달하는 공격입니다.

신뢰할 수 있는 유형은 DOM XSS를 사용하지 않고 애플리케이션을 작성, 보안 검토, 유지관리하는 도구를 제공합니다. CSP를 통해 사용 설정될 수 있으며, 위험한 웹 API에서 특수 객체인 신뢰할 수 있는 유형만 허용하도록 기본적으로 자바스크립트 코드를 안전하게 보호합니다.

이러한 객체를 만들려면 데이터를 DOM에 쓰기 전에 보안 규칙 (예: 이스케이프 처리 또는 삭제)을 일관되게 적용할 수 있는 보안 정책을 정의할 수 있습니다. 이러한 정책은 코드에서 DOM XSS를 발생시킬 수 있는 유일한 위치입니다.

사용 예

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;

신뢰할 수 있는 유형 사용 방법

권장 용도

위험한 DOM 싱크에 신뢰할 수 있는 유형을 적용합니다. CSP 및 신뢰할 수 있는 유형 헤더:
```
Content-Security-Policy: require-trusted-types-for 'script'
```
현재 require-trusted-types-for 지시어에 허용되는 유일한 값은 'script'입니다.

물론 신뢰할 수 있는 유형을 다른 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>


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

    참고:  trusted-types 지시어를 설정하여 허용되는 신뢰할 수 있는 유형 정책의 이름을 제한하지 않는 한 임의의 이름으로 정책을 정의할 수 있습니다. 
  
  
    정책 적용
    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를 문자열과 함께 사용하면 오류가 발생합니다.
  

지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  
자세히 알아보기

  신뢰할 수 있는 유형으로 DOM 기반 교차 사이트 스크립팅 취약점 방지
  CSP: required-trusted-types-for - HTTP |
      MDN
  CSP: 신뢰할 수 있는 유형 - HTTP |
      MDN
  신뢰할 수 있는 유형 데모—DevTools Inspector를 열고 무슨 일이 일어나고 있는지 확인



X-Content-Type-Options

악성 HTML 문서가 도메인에서 제공되면 (예: 사진 서비스에 업로드된 이미지에 유효한 HTML 마크업이 포함된 경우) 일부 브라우저에서는 이를 활성 문서로 취급하여 애플리케이션의 컨텍스트에서 스크립트를 실행하도록 허용하여 교차 사이트 스크립팅 버그를 일으킵니다.

X-Content-Type-Options: nosniff는 주어진 응답의 Content-Type 헤더에 설정된 MIME 유형이 정확하다고 브라우저에 지시하여 이를 방지합니다. 이 헤더는 모든 리소스에 권장됩니다.

사용 예
X-Content-Type-Options: nosniff


  
    
    X-Content-Type-Options 사용 방법


    
      권장 용도
올바른 Content-Type 헤더와 함께 서버에서 제공되는 모든 리소스에는 X-Content-Type-Options: nosniff를 사용하는 것이 좋습니다.

문서 HTML과 함께 전송되는 헤더의 예
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        브라우저 지원
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  64
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  50
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  11
  
  
        
        
        소스
        
      
    
    
    
  
자세히 알아보기

  X-Content-Type-Options - HTTP MDN

    
  


X 프레임 옵션

악성 웹사이트에서 사이트를 iframe으로 삽입할 수 있는 경우 공격자가 클릭재킹을 통해 사용자의 의도치 않은 작업을 호출할 수 있습니다. 스펙터 유형 공격을 통해 악성 웹사이트가 삽입된 문서의 콘텐츠를 파악할 수도 있습니다.

X-Frame-Options는 브라우저가 <frame>, <iframe>, <embed>, <object>에서 페이지를 렌더링할 수 있는지 여부를 나타냅니다. 모든 문서는 이 헤더를 전송하여 다른 문서 삽입이 허용되는지 여부를 나타내는 것이 좋습니다.

참고:  특정 출처만 문서를 삽입할 수 있도록 허용하는 등 더 세부적인 제어가 필요한 경우에는 CSP frame-ancestors 지시어를 사용하세요.  

사용 예
X-Frame-Options: DENY


  
    
    X-Frame-Options 사용 방법


    
      권장 용도
삽입되지 않은 모든 문서는 X-Frame-Options 헤더를 사용해야 합니다.
이 데모에서 다음 구성이 iframe 로드에 어떤 영향을 미치는지 확인해 볼 수 있습니다. X-Frame-Options 드롭다운 메뉴를 변경하고 Reload the iframe 버튼을 클릭합니다.
다른 웹사이트에서 내 웹사이트를 퍼가는 것을 방지합니다.
다른 문서에 의해 삽입되는 것을 거부합니다.

X-Frame-Options: DENY

웹사이트가 교차 출처 웹사이트에서 삽입되지 않도록 보호
동일 출처 문서에 의해서만 삽입이 허용됩니다.
X-Frame-Options: SAMEORIGIN

 기본적으로 문서를 삽입할 수 있으므로 웹 개발자는 삽입을 중지하고 부채널 공격으로부터 보호하기 위해 DENY 또는 SAMEORIGIN를 명시적으로 전송해야 합니다. Chrome팀에서는 명시적으로 헤더를 설정하지 않아도 웹사이트가 안전하게 보호되도록, 기본적으로 문서 삽입을 차단하는 전환을 고려하고 있습니다. 새로운 환경에서는 문서 삽입을 명시적으로 선택해야 합니다. 
지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        브라우저 지원
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
        
        
        소스
        
      
    
    
    
  
자세히 알아보기

  X 프레임 옵션 - HTTP

    
  


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

공격자는 다른 출처(예: 사이트)의 리소스를 삽입하여 웹 기반 교차 사이트 유출을 악용하여 정보를 알 수 있습니다.

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 드롭다운 메뉴를 변경하고 iframe 새로고침 또는 이미지 새로고침 버튼을 클릭하여 효과를 확인합니다.

리소스 로드 허용 cross-origin
CDN 유사 서비스는 일반적으로 교차 출처 페이지에 의해 로드되므로 cross-origin를 리소스에 적용하는 것이 좋습니다. 비슷한 효과가 있는 CORS를 통해 이미 제공되는 경우는 예외입니다.

Cross-Origin-Resource-Policy: cross-origin

same-origin에서 로드되는 리소스 제한
same-origin는 동일한 출처 페이지에서만 로드하려는 리소스에 적용되어야 합니다. 사용자에 대한 민감한 정보 또는 동일한 출처에서만 호출하려는 API의 응답이 포함된 리소스에 적용해야 합니다.
이 헤더가 있는 리소스는 새 브라우저 창에서 URL로 이동하는 등의 방법으로 직접 로드할 수 있습니다. 교차 출처 리소스 정책은 다른 웹사이트에서 리소스를 삽입하지 못하도록만 보호합니다.

Cross-Origin-Resource-Policy: same-origin

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

Cross-Origin-Resource-Policy: same-site

참고:  동일 출처와 동일 사이트의 차이점에 대해 자세히 알아보려면 '동일 사이트'와 '동일 출처'의 이해를 참고하세요. 
지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        브라우저 지원
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  73
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  74
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
        
        
        소스
        
      
    
    
    
  
자세히 알아보기

  교차 출처 리소스 정책 배포 고려하기
  COOP 및 COEP를 사용하여 웹사이트를 '교차 출처 분리'로 만들기
  강력한 기능을 사용하기 위해 '교차 출처 격리'가 필요한 이유

    
  


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

공격자의 웹사이트는 웹 기반 교차 사이트 유출을 악용하여 팝업 창에서 다른 사이트를 열어 정보를 알아볼 수 있습니다. 경우에 따라서는 스펙터 기반 부채널 공격을 악용할 수도 있습니다.

Cross-Origin-Opener-Policy 헤더는 문서가 window.open()를 통해 열린 교차 출처 창 또는 rel="noopener" 없이 target="_blank"가 포함된 링크로부터 스스로를 격리하는 방법을 제공합니다. 따라서 문서의 교차 출처 오프너는 참조가 없으며 이 문서와 상호작용할 수 없습니다.

사용 예
Cross-Origin-Opener-Policy: same-origin-allow-popups


  
    
    COOP 사용 방법


    
      권장 용도
이 데모에서 교차 출처 팝업 창과의 통신에 다음 구성이 어떤 영향을 미치는지 시도해 볼 수 있습니다.
  문서와 팝업 창의 Cross-Origin-Opener-Policy 드롭다운 메뉴를 변경하고 팝업 열기 버튼을 클릭한 다음 postMessage 전송을 클릭하여 메시지가 실제로 전송되었는지 확인합니다.
교차 출처 창에서 문서 격리
same-origin를 설정하면 문서가 교차 출처 문서 창으로부터 격리됩니다.

Cross-Origin-Opener-Policy: same-origin

교차 출처 창에서 문서를 격리하지만 팝업은 허용
same-origin-allow-popups를 설정하면 문서가 same-origin 또는 same-origin-allow-popups로 COOP를 설정하지 않는 한 팝업 창에 관한 참조를 유지할 수 있습니다. 즉, same-origin-allow-popups는 팝업 창으로 열릴 때 문서가 참조되지 않도록 보호할 수 있지만 자체 팝업과 통신하도록 허용합니다.


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

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

 unsafe-none이 기본값이 되면 웹 개발자가 부채널 공격으로부터 웹사이트를 보호하기 위해 same-origin 또는 same-origin-allow-popups를 명시적으로 전송해야 합니다. 
Cross-Origin-Opener-Policy: unsafe-none

참고:  SharedArrayBuffer 또는 performance.measureUserAgentSpecificMemory()와 같은 기능은 기본적으로 사용 중지되어 있습니다. 일부 브라우저에서는 COOP 및 COEP 헤더를 설정해야 하는 '교차 출처 분리' 컨텍스트에서 사용할 수 있습니다. 자세한 내용은 COOP 및 COEP를 사용하여 웹사이트를 '교차 출처 분리'로 만들기를 참고하세요. 
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는 이미지 데이터에 액세스할 수 없습니다.
리소스 제공업체는 CORS를 사용하여 제한을 완화하고 다른 웹사이트에서 리소스를 읽도록 허용할 수 있습니다.

사용 예
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
  
  
        
        
        소스
        
      
    
    
    
  
자세히 알아보기

  교차 출처 리소스 공유 (CORS)
  교차 출처 리소스 공유 (CORS) - HTTP |
      MDN

    
  


교차 출처 삽입 정책 (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를 통해 선택하지 않는 리소스의 로드를 차단하도록 지시할 수 있습니다.


이 데모에서 다음 구성이 리소스 로드에 어떤 영향을 미치는지 확인해 볼 수 있습니다. Cross-Origin-Embedder-Policy 드롭다운 메뉴, Cross-Origin-Resource-Policy 드롭다운 메뉴, 보고서 전용 체크박스 등을 변경하여 리소스 로드에 미치는 영향을 확인합니다. 또한 보고 엔드포인트 데모를 열어 차단된 리소스가 보고되는지 확인하세요.

교차 출처 격리 사용 설정
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와 호환되지 않는 리소스 보고
Reporting API를 사용하여 COEP로 인해 차단된 리소스의 보고서를 수신할 수 있습니다.
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
  
  
        
        
        소스
        
      
    
    
    
  
자세히 알아보기

  COOP 및 COEP를 사용하여 웹사이트를 '교차 출처 분리'로 만들기
  강력한 기능을 사용하기 위해 '교차 출처 격리'가 필요한 이유
  교차 출처 격리 사용 설정 가이드

    
  


HTTP Strict Transport Security (HSTS)

일반 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
  
  
        
        
        소스
        
      
    
    
    
  
자세히 알아보기

  Strict-Transport-Security -
      HTTP

    
  


추가 자료


사후 스펙터 웹 개발