이제 Modern Web Guidance가 안정화되었습니다. 전문가가 검증한 웹 개발 권장사항으로 코딩 에이전트를 업그레이드하세요. 공지 확인하기

Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

보안 헤더 빠른 참조

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

Eiji Kitamura

Artur Janc

Maud Nalpas

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

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

웹의 알려진 위협

보안 헤더를 자세히 알아보기 전에 웹에서 알려진 위협과 이러한 보안 헤더를 사용해야 하는 이유를 알아보세요.

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

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

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

XSS 취약점은 일반적으로 공격자에게 애플리케이션에서 처리하는 사용자 데이터와 동일한 웹 출처에서 호스팅되는 기타 정보에 대한 전체 액세스 권한을 부여할 수 있습니다.

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

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

다른 웹사이트에서 사이트 격리

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

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

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

이러한 헤더에 관심이 있다면 Post-Spectre 웹 개발을 읽어보세요.

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

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

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

사이트 트래픽 암호화

암호화 문제는 애플리케이션이 전송 중 데이터를 완전히 암호화하지 않아 도청 공격자가 사용자와 애플리케이션의 상호작용을 파악할 수 있는 경우에 발생합니다.

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 평가자는 CSP를 평가하는 데 유용한 도구이지만 동시에 nonce 기반의 엄격한 CSP 예시이기도 합니다. DevTools를 사용하여 사용 방법을 확인합니다.

지원되는 브라우저

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

CSP에 관한 기타 참고사항

frame-ancestors 지시문은 신뢰할 수 없는 사이트에서 내 사이트를 삽입하도록 허용하는 경우 발생하는 위험인 클릭재킹으로부터 사이트를 보호합니다. 더 간단한 솔루션을 선호하는 경우 X-Frame-Options를 사용하여 로드를 차단할 수 있지만 frame-ancestors를 사용하면 특정 출처만 삽입자로 허용하는 고급 구성을 사용할 수 있습니다.
CSP를 사용하여 사이트의 모든 리소스가 HTTPS를 통해 로드되도록 했을 수 있습니다. 이는 관련성이 낮아졌습니다. 요즘에는 대부분의 브라우저가 혼합 콘텐츠를 차단합니다.
보고서 전용 모드에서 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'
```
현재 '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>


  
    정책 정의
    정책:
    
// 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: require-trusted-types-for - HTTP |
      MDN
  CSP: trusted-types - HTTP |
      MDN
  신뢰할 수 있는 유형 데모: DevTools 검사기를 열고 어떤 일이 일어나는지 확인합니다.



X-Content-Type-Options

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

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

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


  
    
    X-Content-Type-Options 사용 방법


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

문서 HTML과 함께 전송되는 헤더 예시
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        64
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        50
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        11
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
자세히 알아보기

  X-Content-Type-Options - HTTP MDN

    
  


X-Frame-Options

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

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

참고:  특정 출처만 문서를 삽입하도록 허용하는 등 더 세분화된 제어가 필요한 경우 CSP frame-ancestors 지시어를 사용하세요.  

사용 예시
X-Frame-Options: DENY


  
    
    X-Frame-Options 사용 방법


    
      권장 용도
삽입되도록 설계되지 않은 모든 문서는 X-Frame-Options 헤더를 사용해야 합니다.
다른 웹사이트에서 내 웹사이트를 삽입하지 못하도록 보호합니다.
다른 문서에 삽입되지 않도록 거부합니다.

X-Frame-Options: DENY
교차 출처 웹사이트에서 웹사이트를 삽입하지 못하도록 보호합니다.
동일 출처 문서에만 삽입을 허용합니다.
X-Frame-Options: SAMEORIGIN
 문서가 기본적으로 삽입 가능하다는 것은 웹 개발자가 삽입을 중지하고 부채널 공격으로부터 자신을 보호하기 위해 DENY 또는 SAMEORIGIN를 명시적으로 전송해야 한다는 것을 의미합니다. Chrome팀은 웹사이트에서 헤더를 명시적으로 설정하지 않더라도 안전하게 보호되도록 기본적으로 문서 삽입을 차단하는 방식으로 전환하는 것을 고려하고 있습니다. 이 새로운 환경에서는 문서가 삽입되도록 명시적으로 선택해야 합니다. 
지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
자세히 알아보기

  X-Frame-Options - HTTP

    
  


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

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

Cross-Origin-Resource-Policy는 로드할 수 있는 웹사이트 집합을 표시하여 이 위험을 완화합니다. 헤더는 same-origin, same-site, cross-origin의 세 가지 값 중 하나를 사용합니다. 모든 리소스는 이 헤더를 전송하여 다른 웹사이트에서 로드할 수 있는지 여부를 나타내는 것이 좋습니다.

사용 예시
Cross-Origin-Resource-Policy: same-origin


  
    
    CORP 사용 방법


    
      권장 용도
모든 리소스는 다음 세 가지 헤더 중 하나를 사용하여 제공하는 것이 좋습니다.
리소스 로드 허용 cross-origin
CDN과 유사한 서비스는 이미 유사한 효과가 있는 CORS를 통해 제공되지 않는 한 리소스에 cross-origin를 적용하는 것이 좋습니다(일반적으로 교차 출처 페이지에서 로드되기 때문).

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
참고:  동일 출처와 동일 사이트의 차이점에 관한 자세한 내용은 '동일 사이트' 및 '동일 출처' 이해하기를 참고하세요. 
지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        73
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        74
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
자세히 알아보기

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

    
  


교차 출처 opener 정책(COOP)

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

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

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


  
    
    COOP 사용 방법


    
      권장 용도
교차 출처 창에서 문서 격리
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"
지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
자세히 알아보기

  강력한 기능을 위해 '교차 출처 분리'가 필요한 이유

    
  


교차 출처 리소스 공유(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 헤더에 있더라도 인증된 요청이 거부됩니다.

프리플라이트 요청
프리플라이트 요청은 후속 요청을 전송할 수 있는지 확인하기 위해 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초 동안 캐시할 수 있음을 나타냅니다.

지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        3.5
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
자세히 알아보기

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

    
  


교차 출처 삽입 정책(COEP)

Spectre 기반 공격이 교차 출처 리소스를 도용하는 것을 방지하기 위해 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: 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"
지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
자세히 알아보기

  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
지원되는 브라우저

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        7
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
자세히 알아보기

  Strict-Transport-Security -
      HTTP

    
  


추가 자료


스펙터 이후의 웹 개발


    
  
  
    
      
      이전
      
        arrow_back
      
      
        '동일 사이트' 및 '동일 출처' 이해하기

보안 헤더 빠른 참조 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

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

다른 웹사이트에서 사이트 격리

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

사이트 트래픽 암호화

콘텐츠 보안 정책(CSP)

권장 용도

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

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

지원되는 브라우저

CSP에 관한 기타 참고사항

자세히 알아보기

신뢰할 수 있는 유형

권장 용도

지원되는 브라우저

자세히 알아보기

X-Content-Type-Options

권장 용도

지원되는 브라우저

자세히 알아보기

X-Frame-Options

권장 용도

다른 웹사이트에서 내 웹사이트를 삽입하지 못하도록 보호합니다.

교차 출처 웹사이트에서 웹사이트를 삽입하지 못하도록 보호합니다.

지원되는 브라우저

자세히 알아보기

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

권장 용도

리소스 로드 허용 cross-origin

same-origin에서 로드할 리소스 제한

same-site에서 로드할 리소스 제한

지원되는 브라우저

자세히 알아보기

교차 출처 opener 정책(COOP)

권장 용도

교차 출처 창에서 문서 격리

교차 출처 창에서 문서를 분리하지만 팝업 허용

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

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

지원되는 브라우저

자세히 알아보기

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

권장 용도

간단한 요청

프리플라이트 요청

지원되는 브라우저

자세히 알아보기

교차 출처 삽입 정책(COEP)

사용 예시

교차 출처 격리 사용 설정

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

지원되는 브라우저

자세히 알아보기

HTTP Strict Transport Security (HSTS)

권장 용도

지원되는 브라우저

자세히 알아보기

추가 자료

보안 헤더 빠른 참조

리소스 로드 허용 `cross-origin`

`same-origin`에서 로드할 리소스 제한

`same-site`에서 로드할 리소스 제한