requestStorageAccessFor API

1. 소개

이 절은 비규범적이다.

많은 사용자 에이전트는 콘텐츠가 쿠키에 저장된 비-동일 사이트 데이터에 액세스하지 못하게 한다. 이로 인해 비-동일 사이트 쿠키 액세스에 의존하는 삽입된 콘텐츠가 작동하지 않을 수 있다.

requestStorageAccessFor API를 사용하면 개발자가 iframe, 스크립트 또는 이미지와 같은 삽입된 리소스에 대해 비-동일 사이트 쿠키 액세스를 요청할 수 있다. 이는 requestStorageAccessFor(requestedOrigin)을 지정하여 이루어지며, 이를 통해 순회 가능한 내비게이블이 다른 오리진을 대신하여 비파티션 쿠키에 대한 액세스를 요청할 수 있다.

2. 인프라

이 명세는 Infra 표준에 의존한다. [INFRA]

3. requestStorageAccessFor API

이 명세는 다른 오리진을 대신하여 비파티션 데이터에 대한 액세스를 요청하는 데 사용할 수 있는 메서드(requestStorageAccessFor(requestedOrigin))를 정의한다.

Alex가 https://social.example/을 방문한다. 페이지가 쿠키를 설정한다. 이 쿠키는 퍼스트 파티 사이트 컨텍스트에서 설정되었다.

나중에 Alex가 https://video.example/을 방문하며, 여기에는 https://social.example/profile-image를 로드하는 img가 있다. 이 경우 social.example의 Document doc은 서드 파티 컨텍스트에 있으며, 이전에 설정된 쿠키는 사용자 에이전트의 스토리지 액세스 정책에 따라 doc.cookie에서 보일 수도 있고 보이지 않을 수도 있다.

https://video.example/의 스크립트는 USVString requestedOrigin으로 https://social.example을 사용하여 doc.requestStorageAccessFor(requestedOrigin)을 호출함으로써 https://social.example을 대신하여 액세스를 요청할 수 있다.

참고: 액세스 사용 조건은 요청된 오리진이 공유에 동의한 경우로 제한되어야 한다. 자세한 내용은 § 7 개인정보 보호 고려 사항 및 § 8 보안 고려 사항에서 확인할 수 있다.

비파티션 데이터란 사이트가 퍼스트 파티 사이트 컨텍스트에서 로드되었을 때 사용할 수 있는 클라이언트 측 스토리지이다.

Document가 순회 가능한 내비게이블의 활성 문서이면 퍼스트 파티 사이트 컨텍스트에 있다. 그렇지 않은 경우, 해당 문서가 활성 문서이고 그 관련 설정 객체의 오리진과 최상위 오리진이 서로 동일 사이트이면 퍼스트 파티 사이트 컨텍스트에 있다.

Document가 퍼스트 파티 사이트 컨텍스트에 있지 않으면 서드 파티 컨텍스트에 있다.

3.1. `Document` 변경 사항

partial interface Document {
  Promise<undefined> requestStorageAccessFor(USVString requestedOrigin);
};

Document doc에서 USVString requestedOrigin을 사용하여 호출할 때, requestStorageAccessFor(requestedOrigin) 메서드는 다음 단계를 실행해야 한다:

p를 새 프로미스로 설정한다.
doc이 완전히 활성 상태가 아니면, "InvalidStateError" DOMException으로 p를 거부하고 p를 반환한다.
doc의 노드 내비게이블이 순회 가능한 내비게이블이 아니면, "NotAllowedError" DOMException으로 p를 거부하고 p를 반환한다.
doc의 오리진이 불투명 오리진이면, "NotAllowedError" DOMException으로 p를 거부하고 p를 반환한다.
doc의 관련 전역 객체가 보안 컨텍스트가 아니면, "NotAllowedError" DOMException으로 p를 거부하고 p를 반환한다.
parsedURL을 requestedOrigin에 대해 URL 파서를 실행한 결과로 설정한다.
parsedURL이 실패이면, TypeError로 p를 거부하고 p를 반환한다.
origin을 parsedURL의 오리진으로 설정한다.
origin이 불투명 오리진이면, "NotAllowedError" DOMException으로 p를 거부하고 p를 반환한다.
doc의 오리진이 origin과 동일 오리진이면, p를 이행하고 반환한다.
descriptor를 TopLevelStorageAccessPermissionDescriptor의 새 인스턴스로 설정하고, name을 "top-level-storage-access"로 설정하며, requestedOrigin을 origin으로 설정한다.
doc의 Window 객체에 일시적 활성화가 있으면 has activation을 true로, 그렇지 않으면 false로 설정한다.
다음 단계를 병렬로 실행한다:
1. settings를 doc의 관련 설정 객체로 설정한다.
2. global을 doc의 관련 전역 객체로 설정한다.
3. existing state를 settings에 대한 descriptor의 권한 상태로 설정한다.
4. existing state가 허용됨이면:
  1. global을 사용하여 권한 태스크 소스에 p를 이행하는 전역 태스크를 큐에 추가한다.
  2. 반환한다.
5. existing state가 거부됨이면:
  1. doc의 Window 객체에 일시적 활성화가 있으면, 이를 사용하여 사용자 활성화를 소비한다.
  2. global을 사용하여 권한 태스크 소스에 "NotAllowedError" DOMException으로 p를 거부하는 전역 태스크를 큐에 추가한다.
  3. 반환한다.
6. doc의 노드 내비게이블이 순회 가능한 내비게이블이라고 단언한다.
7. has activation이 false이면:
  1. global을 사용하여 권한 태스크 소스에 "NotAllowedError" DOMException으로 p를 거부하는 전역 태스크를 큐에 추가한다.
  2. 반환한다.
8. permissionState를 descriptor와 함께 "top-level-storage-access" 사용 권한을 요청한 결과로 설정한다.
  
  참고: 권한을 요청하고 프롬프트를 표시할지 결정할 때 사용자 에이전트는 최종 사용자 경험을 구성하기 위해 구현 정의 동작을 적용한다. 특히 top-level-storage-access의 경우, 사용자 에이전트는 프롬프트를 표시하지 않고 권한을 허용하거나 거부하는 사용자 지정 규칙을 적용하는 것으로 알려져 있다.
9. permissionState가 허용됨이면:
  1. global을 사용하여 권한 태스크 소스에 p를 이행하는 전역 태스크를 큐에 추가한다.
  2. 반환한다.
10. doc의 Window 객체에 일시적 활성화가 있으면, 이를 사용하여 사용자 활성화를 소비한다.
11. global을 사용하여 권한 태스크 소스에 "NotAllowedError" DOMException으로 p를 거부하는 전역 태스크를 큐에 추가한다.
p를 반환한다.

권한 태스크 소스를 직접 사용해서는 안 된다. [privacycg/requestStorageAccessFor 이슈 #15]

3.2. 사용자 에이전트의 최상위 스토리지 액세스 정책

요청 request가 최상위 스토리지 액세스를 갖는지 확인하려면 다음 단계를 실행한다:

settings를 request의 클라이언트의 관련 전역 객체의 관련 설정 객체로 설정한다.
embedded origin을 request의 URL의 오리진으로 설정한다.
descriptor를 TopLevelStorageAccessPermissionDescriptor의 새 인스턴스로 설정하고, name을 "top-level-storage-access"로 설정하며, requestedOrigin을 embedded origin으로 설정한다.
existing state를 settings에 대한 descriptor의 권한 상태로 설정한다.
existing state가 허용됨이면 true를 반환한다.
false를 반환한다.

4. 권한 통합

requestStorageAccessFor API는 이름 "top-level-storage-access"로 식별되는 강력한 기능을 정의한다. 이 API는 다음과 같은 권한 관련 알고리즘을 정의한다:

PermissionDescriptor

"top-level-storage-access" 강력한 기능은 다음과 같이 PermissionDescriptor를 정의한다:

dictionary TopLevelStorageAccessPermissionDescriptor : PermissionDescriptor {
    USVString requestedOrigin = "";
};

권한 질의 알고리즘

PermissionDescriptor permissionDesc와 PermissionStatus status가 주어졌을 때, "top-level-storage-access" 권한을 질의하려면 다음 단계를 실행한다:

status의 state를 permissionDesc의 권한 상태로 설정한다.
status의 state가 거부됨이면, status의 state를 프롬프트로 설정한다.

참고: 사용자 결정을 개발자에게 노출하지 않기 위해 거부됨 권한 상태는 공개되지 않는다. 이는 사용자에 대한 보복과 사용자 경험에 해를 끼치는 반복적인 프롬프트 표시를 방지하기 위한 것이다.

권한 키 유형

"top-level-storage-access" 기능의 권한 키는 사이트 유형을 갖는다.

참고: requestedOrigin 필드는 권한 저장소 항목이 이중 키로 구성되도록 한다.

권한 키 생성 알고리즘

오리진 origin과 오리진 embedded origin이 주어졌을 때, "top-level-storage-access" 기능의 새 권한 키를 생성하려면 다음 단계를 실행한다:

embedded origin이 origin과 동일 사이트가 아니면 null을 반환한다.
origin에서 사이트를 얻은 결과를 반환한다.

참고: embedded origin이 origin과 동일 사이트인지 확인하는 검사는 교차 사이트 프레임에서 권한을 질의하지 못하게 하기 위한 것이다. 이는 top-level-storage-access 권한 요청이 최상위 브라우징 컨텍스트에서만 허용된다는 불변 조건에 의존한다. 따라서 이 검사는 query(permissionDesc)에서만 관련된다.

권한 키 비교 알고리즘

"top-level-storage-access" 기능의 권한 키 key1과 key2를 비교하려면 다음 단계를 실행한다:

key1이 null이거나 key2가 null이면 false를 반환한다.
key1이 key2와 동일 사이트인지 여부를 반환한다.

5. Fetch 통합

requestStorageAccessFor(requestedOrigin)은 최상위 문서에서 요청된 오리진으로 전송되는 하위 리소스 요청의 쿠키 동작에만 직접적인 영향을 준다.

HTTP 네트워크 또는 캐시 가져오기에서 쿠키를 차단할지 결정할 때 다음 알고리즘을 실행한다. 결과가 true이면 쿠키 차단을 해제할 수 있음을 의미한다:

has top-level access를 request에 대해 요청이 최상위 스토리지 액세스를 갖는지 확인한 결과로 설정한다.
has top-level access가 false이면 false를 반환한다.
request가 하위 리소스 요청이면 is subresource를 true로, 그렇지 않으면 false로 설정한다.
request의 모드가 "cors"이고 request의 자격 증명 모드가 "include"이면 allowed subresource mode를 true로, 그렇지 않으면 false로 설정한다.
is subresource가 true이고 allowed subresource mode가 false이면 false를 반환한다.
request의 클라이언트의 관련 전역 객체의 연결된 문서가 순회 가능한 내비게이블이 아니면 false를 반환한다.
true를 반환한다.

6. Storage Access API 통합

참고: requestStorageAccessFor(requestedOrigin) 호출이 성공한 후에도 프레임이 쿠키에 액세스하려면 requestStorageAccess()를 명시적으로 호출해야 한다. 이 수정 사항을 통해 requestStorageAccessFor(requestedOrigin)이 이전에 성공한 requestStorageAccess() 허용과 유사하게 requestStorageAccess() 호출을 이행할 수 있다.

requestStorageAccess()를 수정하여 13.4단계 이전, 즉 일시적 활성화를 확인하기 전에 다음 단계를 삽입한다:

settings를 doc의 관련 설정 객체로 설정한다.
origin을 settings의 오리진으로 설정한다.
descriptor를 TopLevelStorageAccessPermissionDescriptor의 새 인스턴스로 설정하고, name을 "top-level-storage-access"로 설정하며, requestedOrigin을 origin으로 설정한다.
descriptor의 권한 상태가 허용됨이면, global을 사용하여 권한 태스크 소스에 p를 이행하는 전역 태스크를 큐에 추가하고 반환한다.
descriptor의 권한 상태가 거부됨이면, global을 사용하여 권한 태스크 소스에 "NotAllowedError" DOMException으로 p를 거부하는 전역 태스크를 큐에 추가하고 반환한다.

7. 개인정보 보호 고려 사항

[STORAGE-ACCESS]와 마찬가지로, requestStorageAccessFor(requestedOrigin)은 교차 사이트 쿠키를 제거할 수 있도록 하기 위한 것이다. 이를 통해 개발자는 추가 제약 조건 아래에서 교차 사이트 쿠키를 다시 사용할 수 있다.

참고: Storage Access API § 6 개인정보 보호 고려 사항에 있는 동일한 고려 사항이 다수 적용된다. 이 절에서는 주로 차이점을 다룬다.

requestStorageAccess()는 삽입된 문서와의 상호작용을 요구한다. requestStorageAccessFor(requestedOrigin)은 최상위 문서와의 상호작용만 요구하므로 잠재적인 프롬프트 표시 기준을 낮추지만, 삽입된 문서도 상당히 눈에 띌 수 있으며 사용자 상호작용을 얻기 위해 다른 기법을 사용할 수도 있다. 구현 정의 허용 및 거부 단계는 사용자 에이전트가 적절하다고 판단한 논리에 따라 악의적인 요청을 거부할 수 있도록 하기 위한 것이다. 사용되는 프롬프트는 사용자가 누가 액세스를 요청하는지 이해할 수 있도록 요청의 방향을 명확히 나타내야 한다.

requestStorageAccess()와 마찬가지로, requestStorageAccessFor(requestedOrigin)에도 사용자 동의와 프롬프트 피로 사이에 동일한 긴장이 존재한다. Storage Access API와 마찬가지로, 구현 정의 허용 및 거부 단계는 이 문제에 대해 서로 다른 입장을 가진 구현자가 적절하다고 판단한 절충안을 선택할 수 있도록 하기 위한 것이다.

또 다른 차이점은 컨텍스트에 따라 권한 질의가 더 민감할 수 있다는 것이다. 프레임은 다음 중 어느 상태도 요청할 수 없어야 한다:

최상위 문서였을 때 특정 오리진에 대한 "top-level-storage-access" 권한이 허용되었는지 여부.
현재 최상위 사이트에서 임의의 다른 오리진에 "top-level-storage-access" 권한이 허용되었는지 여부.

앞의 경우에는 가짜 도메인 또는 그 조합을 식별자로 사용할 수 있게 되며, 뒤의 경우에는 관련 없는 오리진 아래의 상태가 노출된다.

8. 보안 고려 사항

requestStorageAccessFor(requestedOrigin)은 교차 사이트 쿠키가 제거된 이후와 비교하더라도 웹 플랫폼의 보안 속성을 저하시키지 않아야 한다. 서드 파티 쿠키 제거는 특히 CSRF처럼 인증된 요청에 의존하는 공격을 완화함으로써 보안상 잠재적인 이점이 있다. requestStorageAccessFor(requestedOrigin)이 이러한 공격에 악용될 발판이 되는 것은 바람직하지 않다.

참고: Storage Access API § 7 보안 고려 사항의 속성은 이 제안의 많은 부분에 적용된다. 특히 프레임 수준 액세스는 requestStorageAccess()가 성공적으로 호출된 후에만 허용된다. 프레임 액세스와 관련하여 requestStorageAccessFor(requestedOrigin)은 활성화 및 프롬프트 요구 사항을 단순화할 뿐이다.

requestStorageAccessFor(requestedOrigin)은 두 영역, 즉 최상위 문서에서 이루어지는 하위 리소스 요청과 잠재적인 알림 남용에서 고려 사항의 범위를 확장한다.

8.1. 하위 리소스 요청

API에서 제안하는 구체적인 보안 제어는 다음과 같다:

하위 리소스 요청에 포함되는 모든 쿠키는 서드 파티 컨텍스트에서 사용하려는 의도를 나타내도록 명시적으로 SameSite=None으로 표시되어야 한다.
SameSite=None 쿠키가 포함되려면 요청의 모드가 "cors"여야 한다. 이 모드에서는 삽입되는 쪽이 적절한 `access-control-allow-credentials` 헤더를 전송하여 명시적으로 동의하지 않는 한 응답 읽기가 차단된다. `origin` 헤더를 전송하면 삽입되는 쪽이 삽입하는 쪽의 신원을 알 수 있다.

또한 최상위 문서에서 시작된 요청만 SameSite=None 쿠키를 포함할 수 있다. 이를 통해 다른 삽입된 프레임에 상향된 권한이 부여되지 않도록 한다.

8.2. 알림 남용

[STORAGE-ACCESS]와 달리 삽입된 문서가 아니라 최상위 문서와의 상호작용만 필요하다. 이로 인해 프롬프트가 표시될 가능성이 증가한다.

Storage Access API와 마찬가지로 거부 시 사용자 활성화가 소비되므로 반복 요청을 방지한다.

구현 정의 거부 단계에서는 악의적인 행위자에게 수치 제한이나 거부 목록을 적용할 수도 있다.

§ 7 개인정보 보호 고려 사항에서 언급했듯이, 요청 방향 때문에 사용자 에이전트의 프롬프트 문구는 어떤 사이트가 스토리지 액세스 요청을 시작했는지 나타내야 한다.

requestStorageAccessFor API

커뮤니티 그룹 보고서 초안, 2025년 10월 17일

초록

이 문서의 상태

1. 소개

2. 인프라

3. requestStorageAccessFor API

3.1. `Document` 변경 사항

3.2. 사용자 에이전트의 최상위 스토리지 액세스 정책

4. 권한 통합

5. Fetch 통합

6. Storage Access API 통합

7. 개인정보 보호 고려 사항

8. 보안 고려 사항

8.1. 하위 리소스 요청

8.2. 알림 남용

적합성

문서 규약

색인

이 명세에서 정의한 용어

참조로 정의된 용어

참고 문헌

규범적 참고 문헌

정보 제공용 참고 문헌

IDL 색인

이슈 색인

초록

이 문서의 상태

1. 소개

2. 인프라

3. requestStorageAccessFor API

3.1. Document 변경 사항

3.2. 사용자 에이전트의 최상위 스토리지 액세스 정책

4. 권한 통합

5. Fetch 통합

6. Storage Access API 통합

7. 개인정보 보호 고려 사항

8. 보안 고려 사항

8.1. 하위 리소스 요청

8.2. 알림 남용

적합성

문서 규약

색인

이 명세에서 정의한 용어

참조로 정의된 용어

참고 문헌

규범적 참고 문헌

정보 제공용 참고 문헌

IDL 색인

이슈 색인

3.1. `Document` 변경 사항