스토리지 액세스의 HTTP 헤더 지원을 위한 오리진 트라이얼

Natalia Markoborodova
Natalia Markoborodova
X GitHub 글리치

Chrome은 버전 130의 Storage Access API(SAA)에 HTTP 헤더를 추가하기 위한 오리진 트라이얼(Storage Access Headers)을 시작합니다. 새로운 Sec-Fetch-Storage-Access 요청 헤더와 Activate-Storage-Access 응답 헤더는 iframe이 아닌 리소스를 지원하고 소셜 미디어 위젯, 캘린더, 양방향 도구와 같이 삽입된 콘텐츠를 사용하는 웹사이트의 성능과 사용자 환경을 개선하는 것을 목표로 합니다.

JavaScript 흐름 (및 제한사항)

이전에는 사용자가 이미 권한을 부여했더라도 새로고침할 때마다 document.requestStorageAccess()에 대한 JavaScript API 호출이 필요했습니다. 이 방법은 효과적이지만 다음과 같은 제한사항이 있습니다.

  • 여러 번의 네트워크 왕복: 삽입된 콘텐츠가 완전히 작동하기 전에 여러 번의 네트워크 요청과 페이지 새로고침이 필요한 경우가 많았습니다.
  • iframe 종속 항목: JavaScript 실행은 iframe 내에서 iframe 또는 하위 리소스를 사용하도록 강제하여 개발자의 유연성을 제한했습니다.

예를 들어 JavaScript만 사용하여 website.example에 삽입된 calendar.example의 캘린더 위젯은 다음과 같습니다.

  1. 자리표시자 로드: website.example가 위젯을 요청합니다. website.example에 삽입된 calendar.example 위젯은 파티션되지 않은 쿠키에 액세스할 수 없으므로 자리표시자 위젯이 대신 렌더링됩니다.
  2. 권한 요청: 자리표시자가 로드된 후 document.requestStorageAccess()를 호출하여 storage-access 권한을 요청합니다.
  3. 사용자가 권한을 부여하도록 선택합니다.
  4. 위젯 새로고침: 이번에는 쿠키 액세스 권한이 있는 상태로 위젯이 새로고침되고 최종적으로 맞춤 콘텐츠가 로드됩니다.
  5. 사용자가 calendar.example 위젯을 삽입한 사이트를 다시 방문할 때마다 흐름은 1, 2, 4 단계와 정확히 동일합니다. 단, 사용자가 액세스 권한을 다시 부여할 필요가 없다는 점이 다릅니다.

이 흐름은 비효율적입니다. 사용자가 이미 저장소 권한을 부여한 경우 초기 iframe 로드, document.requestStorageAccess() 호출, 후속 새로고침이 불필요해지고 지연 시간이 발생합니다.

HTTP 헤더를 사용한 새로운 흐름

새로운 저장소 액세스 헤더를 사용하면 iframe이 아닌 리소스를 포함하여 삽입된 콘텐츠를 더 효율적으로 로드할 수 있습니다.

저장소 액세스 헤더를 사용하면 사용자가 이미 권한을 부여한 경우 브라우저가 Sec-Fetch-Storage-Access: inactive 요청 헤더가 설정된 리소스를 자동으로 가져옵니다. 요청 헤더를 설정하는 데 개발자 작업이 필요하지 않습니다. 서버는 Activate-Storage-Access: retry; allowed-origin="<origin>" 헤더로 응답할 수 있으며 브라우저는 필요한 사용자 인증 정보로 요청을 다시 시도합니다.

요청 헤더

Sec-Fetch-Storage-Access: <access-status>

사용자가 교차 사이트 콘텐츠를 삽입하는 페이지를 방문하면 브라우저는 사용자 인증 정보 (예: 쿠키)가 필요할 수 있는 교차 사이트 요청에 Sec-Fetch-Storage-Access 헤더를 자동으로 포함합니다. 이 헤더는 삽입의 쿠키 액세스 권한 상태를 나타냅니다. 값을 해석하는 방법은 다음과 같습니다.

  • none: 삽입에 storage-access 권한이 없으므로 파티션되지 않은 쿠키에 액세스할 수 없습니다.
  • inactive: 삽입에 storage-access 권한이 있지만 사용하도록 선택하지 않았습니다. 삽입에 파티션되지 않은 쿠키 액세스 권한이 없습니다.
  • active: 삽입에 파티션되지 않은 쿠키 액세스 권한이 있습니다. 이 값은 파티션되지 않은 쿠키에 액세스할 수 있는 교차 출처 요청에 포함됩니다.

응답 헤더

Activate-Storage-Access: <retry-or-reload>

Activate-Storage-Access 헤더는 브라우저에 쿠키를 사용하여 요청을 다시 시도하거나 SAA가 활성화된 상태로 리소스를 직접 로드하도록 지시합니다. 헤더는 다음 값을 가질 수 있습니다.

  • load: 브라우저에 삽입 도구에 요청된 리소스의 파티션되지 않은 쿠키에 대한 액세스 권한을 부여하도록 지시합니다.
  • retry: 서버는 브라우저가 스토리지 액세스 권한을 활성화한 후 요청을 다시 시도해야 한다고 응답합니다.
Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

iframe이 아닌 리소스 지원

저장소 액세스 헤더 업데이트를 통해 다른 도메인에 호스팅된 이미지와 같이 iframe이 아닌 삽입된 콘텐츠에 SAA를 사용할 수 있습니다. 이전에는 서드 파티 쿠키를 사용할 수 없는 경우 브라우저에서 인증 정보가 포함된 이러한 리소스를 로드할 수 있는 웹 플랫폼 API가 없었습니다. 예를 들어 embedding-site.example는 다음과 같이 이미지를 요청할 수 있습니다.

   <img src="https://server.example/image"/>

서버는 쿠키를 사용할 수 있는지 여부에 따라 콘텐츠 또는 오류로 응답할 수 있습니다.

app.get('/image', (req, res) => {
  const headers = req.headers;
  const cookieHeader = headers.cookie;
  // Check if the embed has the necessary cookie access
  if (!cookieHeader || !cookieHeader.includes('foo')) {
  // If the cookie is not present, check if the browser supports Storage Access headers
    if (
      'sec-fetch-storage-access' in headers &&
      headers['sec-fetch-storage-access'] == 'inactive'
    ) {
    // If the browser supports Storage Access API, retry the request with storage access enabled
      res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
    }
    res.status(401).send('No cookie!');
   } else {
    // If the cookie is available, check if the user is authorized to access the image
    if (!check_authorization(cookieHeader)) {
      return res.status(401).send('Unauthorized!');
    }
    // If the user is authorized, respond with the image file
    res.sendFile("path/to/image.jpeg");
  }
});

쿠키를 사용할 수 없는 경우 서버는 Sec-Fetch-Storage-Access 요청 헤더의 값을 확인합니다. 이 값이 inactive로 설정되면 서버는 Activate-Storage-Access: retry 헤더로 응답하여 스토리지 액세스를 사용하여 요청을 다시 시도해야 함을 나타냅니다. 쿠키가 없고 Sec-Fetch-Storage-Access 헤더에 inactive 값이 없으면 이미지가 로드되지 않습니다.

HTTP 헤더 흐름

HTTP 헤더를 사용하면 브라우저는 사용자가 이미 위젯에 저장소 액세스 권한을 부여한 시점을 인식하고 후속 방문 중에 파티션되지 않은 쿠키에 액세스할 수 있는 iframe을 로드할 수 있습니다.

저장소 액세스 헤더를 사용하면 후속 페이지 방문 시 다음 흐름이 트리거됩니다.

  1. 사용자가 calendar.example가 삽입된 website.example를 다시 방문합니다. 이 가져오기는 이전과 마찬가지로 아직 쿠키에 액세스할 수 없습니다. 하지만 사용자는 이전에 storage-access 권한을 부여했으며 가져오기에 파티션되지 않은 쿠키 액세스가 가능하지만 사용되지 않음을 나타내는 Sec-Fetch-Storage-Access: inactive 헤더가 포함되어 있습니다.
  2. calendar.example 서버는 Activate-Storage-Access: retry; allowed-origin="<origin>" 헤더 (이 경우 <origin>는 https://website.example)로 응답하여 리소스 가져오기에 저장소 액세스 권한이 있는 파티션되지 않은 쿠키를 사용해야 함을 나타냅니다.
  3. 브라우저가 이번에는 파티션되지 않은 쿠키를 포함하여 요청을 다시 시도합니다 (이 가져오기에 storage-access 권한 활성화).
  4. calendar.example 서버는 맞춤설정된 iframe 콘텐츠로 응답합니다. 응답에는 브라우저가 storage-access 권한이 활성화된 상태로 콘텐츠를 로드해야 함을 나타내는 Activate-Storage-Access: load 헤더가 포함됩니다. 즉, document.requestStorageAccess()가 호출된 것처럼 파티션되지 않은 쿠키 액세스로 로드됩니다.
  5. 사용자 에이전트는 storage-access 권한을 사용하여 파티션을 나누지 않은 쿠키 액세스로 iframe 콘텐츠를 로드합니다. 이 단계를 완료하면 위젯이 정상적으로 작동할 수 있습니다.
저장소 액세스 헤더 흐름을 보여주는 플로우 차트
저장소 액세스 헤더 흐름 다이어그램

솔루션 업데이트

스토리지 액세스 헤더 기능을 사용하면 다음 두 가지 경우에 코드를 업데이트해야 할 수 있습니다.

  1. SAA를 사용하고 있으며 헤더 로직으로 실적을 개선하려고 합니다.
  2. 서버의 요청에 Origin 헤더가 포함되는지에 따라 달라지는 유효성 검사 또는 로직이 있습니다.

SAA 헤더 로직 구현

솔루션에서 스토리지 액세스 헤더를 사용하려면 솔루션을 업데이트해야 합니다. calendar.example 소유자라고 가정해 보겠습니다. website.example가 맞춤설정된 calendar.example 위젯을 로드하려면 위젯 코드에 스토리지 액세스 권한이 있어야 합니다.

클라이언트 측

저장소 액세스 헤더 기능을 사용하기 위해 기존 솔루션의 클라이언트 측에서 코드를 업데이트할 필요는 없습니다. 문서에서 SAA를 구현하는 방법을 알아보세요.

서버 측

서버 측에서는 다음과 같은 새 헤더를 사용할 수 있습니다.

app.get('/cookie-access-endpoint', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // User needs to grant permission, trigger a prompt
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(`${req.headers.origin} is not allowed to send` +
          ' credentialed requests to this server.');
      return;
    }
    res.set('Activate-Storage-Access', `retry; allowed-origin="${req.headers.origin}"`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

데모를 확인하여 이 솔루션이 실제로 작동하는 방식을 알아보세요.

출처 헤더 로직 업데이트

스토리지 액세스 헤더를 사용하면 Chrome이 이전보다 더 많은 요청에 Origin 헤더를 전송합니다. 서버 측 로직이 특정 유형의 요청 (예: CORS에서 정의한 요청)에만 Origin 헤더가 있는 것을 사용하는 경우 영향을 받을 수 있습니다.

잠재적인 문제를 방지하려면 서버 측 코드를 검토해야 합니다.

  • Origin 헤더의 존재 여부에 종속되는 유효성 검사 또는 로직이 있는지 확인합니다.
  • 더 많은 경우에 Origin 헤더가 있는 경우를 처리하도록 코드를 업데이트합니다.

주요 이점

저장소 액세스 헤더는 SAA를 사용하는 더 나은 성능의 권장 방법입니다. 이번 변경사항에는 다음과 같은 몇 가지 개선사항이 있습니다.

  • iframe 외 삽입 지원: 더 다양한 리소스에 SAA를 사용 설정합니다.
  • 네트워크 사용량 감소: 요청 수가 줄고 페이로드 크기가 작아집니다.
  • CPU 사용량 감소: JavaScript 처리가 줄어듭니다.
  • 개선된 UX: 중단되는 중간 로드를 제거합니다.

오리진 트라이얼 참여

오리진 트라이얼을 통해 새로운 기능을 사용해 보고 사용성, 실용성, 효과에 관한 의견을 제공할 수 있습니다. 자세한 내용은 출처 무료 체험판 시작하기를 참고하세요.

Chrome 130부터 오리진 트라이얼에 등록하여 스토리지 액세스 헤더 기능을 사용해 볼 수 있습니다. 오리진 트라이얼에 참여하려면 다음 단계를 따르세요.

  1. 스토리지 액세스 헤더 출처 체험판 등록 페이지로 이동합니다.
  2. 원본 체험판 참여에 관한 안내를 따르세요.

로컬에서 테스트

스토리지 액세스 헤더 기능을 로컬에서 테스트하여 웹사이트가 이러한 변경사항에 대비할 수 있는지 확인할 수 있습니다.

Chrome 인스턴스를 구성하려면 다음 단계를 따르세요.

  1. chrome://flags/#storage-access-headers에서 Chrome 플래그를 사용 설정합니다.
  2. 변경사항이 적용되도록 Chrome을 다시 시작합니다.

참여 및 의견 공유

의견이 있거나 문제가 발생하면 문제를 신고할 수 있습니다. GitHub 설명에서 저장소 액세스 헤더에 관해 자세히 알아볼 수도 있습니다.