COEP를 사용하여 CORP 헤더 없이 교차 출처 리소스 로드: 사용자 인증 정보 없음

타사에서 제공하는 교차 출처 리소스에는 적절한 CORP 헤더가 포함되지 않은 경우가 많습니다. 사용자 인증 정보 없이 요청할 수 있는 경우 이제 이를 표시하여 교차 출처 격리를 사용 설정할 수 있습니다.

브라우저에서 쿠키와 같은 사용자 인증 정보 없이 요청을 전송하여 CORP (교차 출처 리소스 정책)를 사용하지 않는 교차 출처 리소스를 로드할 수 있도록 하는 새로운 교차 출처 삽입 정책 (COEP) 값 credentialless가 출시되었습니다. 이를 통해 개발자는 교차 출처 격리를 더 쉽게 채택할 수 있습니다.

교차 출처 격리가 필요한 이유

일부 웹 API는 스펙터와 같은 부채널 공격의 위험을 높입니다. 이러한 위험을 완화하기 위해 브라우저는 교차 출처 격리라는 선택 기반의 격리 환경을 제공합니다. 교차 출처 분리 상태를 사용하면 웹페이지에서 SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), 해상도가 더 높은 고정밀도 타이머와 같은 권한 있는 기능을 사용할 수 있으며 출처가 선택되지 않은 경우 출처를 격리할 수 있습니다.

교차 출처 분리를 사용 설정하려면 웹페이지에서 두 개의 HTTP 헤더를 전송해야 합니다.

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

교차 출처 분리 상태에서는 모든 교차 출처 리소스를 CORS로 제공하거나 Cross-Origin-Resource-Policy 헤더가 로드되도록 설정해야 합니다.

교차 출처 격리 사용과 관련된 문제

교차 출처 격리는 웹페이지의 보안이 향상되고 강력한 기능을 사용할 수 있게 해주지만 배포하기가 까다로울 수 있습니다. 가장 큰 문제 중 하나는 모든 교차 출처 리소스에 CORS 또는 CORP를 사용 설정해야 한다는 것입니다. 이러한 헤더가 없는 리소스는 교차 출처 분리 페이지에 브라우저에 의해 로드되지 않습니다.

이러한 교차 출처 리소스는 일반적으로 서드 파티에서 제공하며, 서드 파티에서는 필요한 헤더를 추가하기 어려울 수 있습니다.

하지만 리소스가 로드되어도 안전하다는 것을 우리가 알고 있다면 어떻게 될까요? 실제로, 사용자 인증 정보를 사용하여 요청된 리소스만 위험에 노출됩니다. 이러한 리소스에는 공격자가 직접 로드할 수 없는 민감한 정보가 포함될 수 있기 때문입니다. 즉, 사용자 인증 정보 없이 요청할 수 있는 리소스는 공개적으로 사용 가능하고 로드하기에 안전합니다.

credentialless하여 구출하기

이때 COEP: credentialless가 필요합니다. credentiallessCross-Origin-Embedder-Policy 헤더의 새 값입니다. require-corp와 마찬가지로 교차 출처 분리를 사용 설정할 수 있습니다. 하지만 Cors가 없는 교차 출처 요청에 CORP:cross-origin 헤더가 필요한 대신 사용자 인증 정보 (예: 쿠키) 없이 전송됩니다.

또는 다음 두 헤더를 사용하여 교차 출처 격리를 사용 설정할 수 있습니다.

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

즉, 요청된 교차 출처 서버가 민감한 리소스로 응답할 수 없으며 요청자는 항상 응답에 공개적으로 사용 가능한 정보만 포함되어 있다고 가정할 수 있습니다.

이는 서드 파티 쿠키의 단계적 지원 중단을 위한 브라우저의 계획에도 부합합니다.

데모

이 데모에서 다양한 헤더 옵션을 사용해 볼 수 있습니다. https://cross-origin-isolation.glitch.me

FAQ

credentialless 환경에서 인증된 요청을 보낼 수 있나요?

물론, 요청 모드를 전환하면 응답에 CORS 검사가 필요하게 됩니다. <audio>, <img>, <link>, <script>, <video>와 같은 HTML 태그의 경우 crossorigin="use-credentials"를 명시적으로 추가하여 브라우저에 인증된 요청을 전송하도록 알립니다.

예를 들어 https://www.example.com의 문서에 Cross-Origin-Embedder-Policy: credentialless 헤더가 있더라도 <img src="https://images.example.com/avatar.png" crossorigin="use-credentials">는 인증된 요청을 보냅니다.

fetch() API의 경우 request.mode = 'cors'를 사용할 수 있습니다.

COEP: credentialless의 정보를 제공했으며 COEP: require-corp가 여전히 내 웹사이트에 어떻게 유용한가요?

COEP: require-corp에서는 쿠키가 일부 교차 출처 하위 리소스에 필요한 경우 요청 모드를 CORS로 수동으로 전환할 필요가 없습니다.

credentialless 환경에서 특수 헤더 없이 교차 출처 iframe도 로드할 수 있나요?

아니요. credentialless 환경에서 교차 출처 iframe을 로드하려면 여전히 require-corp와 동일한 조건이 필요합니다. iframe 문서는 두 개의 헤더와 함께 제공되어야 합니다.

  • Cross-Origin-Embedder-Policy: credentialless (또는 require-corp)
  • Cross-Origin-Resource-Policy: cross-origin

다행인 점은 iframe crossorigin="anonymous"을 제공하여 이러한 헤더 없이 교차 출처 iframe 로드를 허용하는 것에 관한 논의가 진행 중이라는 점입니다. 이렇게 하면 헤더 없이 사용자 인증 정보 없이 교차 출처 iframe을 로드할 수 있습니다.

이 기능을 다른 브라우저에서도 사용할 수 있나요?

다음 단계

교차 출처 격리와 관련된 다른 문제를 완화하기 위해 두 가지 업데이트가 추가됩니다.

위의 장애물로 인해 SharedArrayBuffer 변경사항 확장용 Chrome 오리진 트라이얼에 등록한 사용자는 언제 종료될지 궁금할 수 있습니다. 처음에 Chrome 96에서 종료된다고 발표했지만, Chrome 106으로 연기하기로 했습니다.

자료

사진: 마틴 아담스, Unsplash