Chrome에서 크로스 사이트 추적을 줄이기 위해 서드 파티 쿠키에 대한 지원을 단계적으로 중단하고 있습니다. 이는 인증과 같은 사용자 여정에서 삽입된 컨텍스트의 쿠키를 사용하는 사이트와 서비스에 문제가 될 수 있습니다. Storage Access API (SAA)를 사용하면 크로스 사이트 추적을 최대한 제한하면서 이러한 사용 사례를 계속 활용할 수 있습니다.
구현 상태
Storage Access API는 모든 주요 브라우저에서 사용할 수 있지만 브라우저 간에 약간의 구현 차이가 있습니다. 이러한 차이점은 이 게시물의 관련 섹션에서 강조했습니다.
API를 표준화하기 전에 남아 있는 차단 문제를 모두 해결하기 위해 계속 노력하고 있습니다.
Storage Access API란 무엇인가요?
Storage Access API는 브라우저 설정에 의해 액세스가 거부되었을 때 iframe에서 저장소 액세스 권한을 요청할 수 있도록 하는 JavaScript API입니다. 크로스 사이트 리소스 로드에 의존하는 사용 사례가 있는 삽입은 필요에 따라 API를 사용하여 사용자에게 액세스 권한을 요청할 수 있습니다.
저장용량 요청이 승인되면 iframe에서 크로스 사이트 쿠키에 액세스할 수 있으며, 사용자가 최상위 사이트로 크로스 사이트 쿠키를 방문할 때도 이 쿠키를 사용할 수 있습니다.
Storage Access API를 사용하면 최종 사용자에게 최소한의 부담으로 특정 크로스 사이트 쿠키 액세스를 제공하는 동시에 사용자 추적에 흔히 사용되는 일반적인 크로스 사이트 쿠키 액세스를 방지할 수 있습니다.
사용 사례
일부 서드 파티 삽입의 경우 사용자에게 더 나은 환경을 제공하기 위해 크로스 사이트 쿠키에 액세스해야 하며, 서드 파티 쿠키가 지원 중단된 후에는 이러한 기능을 사용할 수 없습니다.
사용 사례는 다음과 같습니다.
- 로그인 세션 세부정보가 필요한 댓글 작성 위젯이 삽입되었습니다.
- 로그인 세션 세부정보가 필요한 소셜 미디어의 '좋아요' 버튼
- 로그인 세션 세부정보가 필요한 삽입된 문서
- 동영상 삽입에 제공되는 프리미엄 환경입니다 (예: 로그인한 사용자에게 광고를 표시하지 않거나 자막에 대한 사용자의 선호도를 확인하거나 특정 동영상 유형을 제한하기 위해).
- 내장된 결제 시스템.
이러한 사용 사례에는 삽입된 iframe에서 로그인 액세스를 유지하는 것이 포함됩니다.
다른 API 대신 Storage Access API를 사용해야 하는 경우
Storage Access API는 서드 파티 쿠키 사용에 대한 대안 중 하나이므로 이 API를 사용해야 하는 경우를 다른 API와 비교하여 이해하는 것이 중요합니다. 다음 두 가지에 모두 해당하는 사용 사례에 적합합니다.
- 사용자는 삽입된 콘텐츠와 상호작용합니다. 즉, 수동 iframe이나 숨겨진 iframe이 아닙니다.
- 사용자가 최상위 컨텍스트에서 삽입된 출처를 방문했습니다. 즉, 출처가 다른 사이트에 삽입되지 않은 경우입니다.
다양한 사용 사례를 위한 대체 API가 있습니다.
- CHIPS (Cookies Having Independent Partitioned State)를 사용하면 개발자는 최상위 사이트별로 별도의 쿠키 jar가 있는 '파티션을 나눈' 저장소에 쿠키를 선택할 수 있습니다. 예를 들어 서드 파티 웹 채팅 위젯은 세션 정보를 저장하기 위해 쿠키를 설정할 수 있습니다. 세션 정보는 사이트별로 저장되므로 위젯이 설정한 쿠키는 이 위젯이 삽입된 다른 웹사이트에서도 액세스할 필요가 없습니다. Storage Access API는 삽입된 서드 파티 위젯이 여러 출처 (예: 로그인한 세션 세부정보 또는 환경설정)에서 동일한 정보를 공유하는 데 의존하는 경우 유용합니다.
- 관련 웹사이트 세트 (RWS)는 조직에서 사이트 간의 관계를 선언하는 방법으로, 브라우저에서 특정 목적을 위해 제한된 서드 파티 쿠키 액세스를 허용합니다. 사이트는 여전히 Storage Access API를 사용하여 액세스를 요청해야 하지만, 집합 내 사이트의 경우 사용자 메시지 없이 액세스 권한을 부여할 수 있습니다.
- FedCM (제휴 사용자 인증 정보 관리)은 제휴 ID 서비스에 대한 개인 정보 보호 접근 방식입니다. Storage Access API는 로그인 후 쿠키 액세스를 처리합니다. 일부 사용 사례의 경우 FedCM은 Storage Access API의 대체 솔루션을 제공하며, 로그인에 중점을 둔 브라우저 메시지를 제공하므로 선호될 수 있습니다. 그러나 FedCM을 채택하려면 일반적으로 코드를 추가로 변경해야 합니다(예: HTTP 엔드포인트 지원).
- 사기 방지, 광고 관련, 측정 API도 있으며 Storage Access API는 이러한 문제를 해결하기 위한 것이 아닙니다.
Storage Access API 사용
Storage Access API에는 약속된 두 가지 메서드가 있습니다.
또한 Permissions API와 통합됩니다. 이를 통해 document.requestStorageAccess() 호출이 자동으로 부여되는지 여부를 나타내는 서드 파티 컨텍스트에서 저장소 액세스 권한의 상태를 확인할 수 있습니다.
hasStorageAccess() 메서드 사용
사이트가 처음 로드되면 hasStorageAccess() 메서드를 사용하여 서드 파티 쿠키에 대한 액세스 권한이 이미 부여되었는지 확인할 수 있습니다.
// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;
async function handleCookieAccessInit() {
if (!document.hasStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
hasAccess = true;
} else {
// Check whether access has been granted via the Storage Access API.
// Note on page load this will always be false initially so we could be
// skipped in this example, but including for completeness for when this
// is not so obvious.
hasAccess = await document.hasStorageAccess();
if (!hasAccess) {
// Handle the lack of access (covered later)
}
}
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
저장소 액세스 권한은 requestStorageAccess(),를 호출한 후에만 iframe 문서에 부여되므로 hasStorageAccess()는 처음에는 항상 false를 반환합니다. 단, 동일한 iframe의 다른 동일 출처 문서에 이미 액세스 권한이 부여된 경우는 예외입니다. HTML 문서에 대한 초기 요청 시 쿠키가 있어야 하는 페이지에 대한 액세스 권한을 부여한 후 새로고침을 허용하기 위해 iframe 내의 동일 출처 탐색에서 권한 부여가 유지됩니다.
requestStorageAccess() 메서드 사용
iframe에 액세스 권한이 없는 경우 requestStorageAccess() 메서드를 사용하여 액세스를 요청해야 할 수 있습니다.
if (!hasAccess) {
try {
await document.requestStorageAccess();
} catch (err) {
// Access was not granted and it may be gated behind an interaction
return;
}
}
처음 요청할 때 사용자는 브라우저 메시지를 사용하여 이 액세스를 승인해야 할 수 있습니다. 그 후 프로미스가 해결되거나 await가 사용되는 경우 예외가 발생합니다.
악용을 방지하기 위해 이 브라우저 메시지는 사용자 상호작용이 있을 때만 표시됩니다. 따라서 requestStorageAccess()는 iframe이 로드되는 즉시 호출되지 않고 사용자가 활성화한 이벤트 핸들러에서 호출해야 합니다.
async function doClick() {
// Only do this extra check if access hasn't already been given
// based on the hasAccess variable.
if (!hasAccess) {
try {
await document.requestStorageAccess();
hasAccess = true; // Can assume this was true if above did not reject.
} catch (err) {
// Access was not granted.
return;
}
}
if (hasAccess) {
// Use the cookies
}
}
document.querySelector('#my-button').addEventListener('click', doClick);
권한 메시지
사용자가 버튼을 처음 클릭하면 일반적으로 주소 표시줄에 브라우저 메시지가 자동으로 표시됩니다. 다음은 Chrome 메시지의 예입니다. 다른 브라우저에서도 비슷한 UI를 사용합니다.
다음과 같은 특정 상황에서는 브라우저에서 메시지를 건너뛰거나 권한이 자동으로 제공될 수 있습니다.
- 페이지와 iframe이 메시지를 수락한 후 지난 30일 동안 사용된 경우
- 삽입된 iframe이 관련 웹사이트 세트의 일부인 경우
- Firefox에서는 처음 5번의 시도 동안 알려진 웹사이트 (최상위 수준에서 상호작용한 웹사이트)에 관한 프롬프트도 건너뜁니다.
또는 특정 상황에서 메시지를 표시하지 않고 메서드가 자동으로 거부될 수 있습니다.
- 사용자가 이전에 iframe이 아닌 최상위 문서로 iframe을 소유한 사이트를 방문하고 상호작용한 적이 없는 경우 즉, Storage Access API는 사용자가 퍼스트 파티 컨텍스트로 이전에 방문한 적이 있는 삽입된 사이트에만 유용합니다.
- 상호작용 후 프롬프트에 대한 사전 승인 없이
requestStorageAccess()메서드가 사용자 상호작용 이벤트 외부에서 호출되는 경우
처음 사용할 때 사용자에게 메시지가 표시되지만, 이후 방문 시 Chrome 및 Firefox에서 사용자가 상호작용하지 않아도, 메시지를 표시하지 않고 requestStorageAccess()를 해결할 수 있습니다. Safari에서는 항상 사용자 상호작용이 필요합니다.
쿠키 액세스는 메시지 또는 사용자 상호작용 없이 부여될 수 있으므로 페이지 로드 시 requestStorageAccess()를 호출하여 이를 지원하는 브라우저 (Chrome 및 Firefox)에서 사용자가 상호작용하기 전에 서드 파티 쿠키 액세스를 얻을 수 있는 경우가 많습니다. 이렇게 하면 사용자가 iframe과 상호작용하기 전에도 서드 파티 크로스 사이트 쿠키에 즉시 액세스하고 더 풍부한 환경을 제공할 수 있습니다. 상황에 따라 사용자 상호작용을 기다리는 것보다 이러한 방식이 더 나은 사용자 환경일 수 있습니다.
storage-access 권한 쿼리 사용
사용자 상호작용 없이 액세스 권한을 부여할 수 있는지 확인하려면 storage-access 권한의 상태를 확인하고 사용자 작업이 필요하지 않은 경우에만 requestStoreAccess()를 미리 호출하세요. 상호작용이 필요할 때 권한을 호출하거나 실패하도록 하는 것이 좋습니다.
이를 통해 로그인 버튼과 같은 다양한 콘텐츠를 표시하여 프롬프트가 필요할 때 이를 미리 처리할 수도 있습니다.
다음 코드는 이전 예에 storage-access 권한 검사를 추가합니다.
// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;
async function hasCookieAccess() {
// Check if Storage Access API is supported
if (!document.requestStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
return true;
}
// Check if access has already been granted
if (await document.hasStorageAccess()) {
return true;
}
// Check the storage-access permission
// Wrap this in a try/catch for browsers that support the
// Storage Access API but not this permission check
// (e.g. Safari and older versions of Firefox).
let permission;
try {
permission = await navigator.permissions.query(
{name: 'storage-access'}
);
} catch (error) {
// storage-access permission not supported. Assume no cookie access.
return false;
}
if (permission) {
if (permission.state === 'granted') {
// Permission has previously been granted so can just call
// requestStorageAccess() without a user interaction and
// it will resolve automatically.
try {
await document.requestStorageAccess();
return true;
} catch (error) {
// This shouldn't really fail if access is granted, but return false
// if it does.
return false;
}
} else if (permission.state === 'prompt') {
// Need to call requestStorageAccess() after a user interaction
// (potentially with a prompt). Can't do anything further here,
// so handle this in the click handler.
return false;
} else if (permission.state === 'denied') {
// Currently not used. See:
// https://github.com/privacycg/storage-access/issues/149
return false;
}
}
// By default return false, though should really be caught by one of above.
return false;
}
async function handleCookieAccessInit() {
hasAccess = await hasCookieAccess();
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
샌드박스 처리된 iframe
샌드박스 처리된 iframe에서 Storage Access API를 사용하는 경우 다음과 같은 샌드박스 권한이 필요합니다.
- Storage Access API에 대한 액세스를 허용하려면
allow-storage-access-by-user-activation가 필요합니다. - JavaScript를 사용하여 API를 호출하도록 허용하려면
allow-scripts가 필요합니다. - 동일 출처 쿠키 및 기타 저장소에 대한 액세스를 허용하려면
allow-same-origin이(가) 필요합니다.
예를 들면 다음과 같습니다.
<iframe sandbox="allow-storage-access-by-user-activation
allow-scripts
allow-same-origin"
src="..."></iframe>
쿠키 요구사항
Chrome에서 Storage Access API로 액세스하려면 크로스 사이트 쿠키가 다음 두 가지 속성으로 설정되어야 합니다.
SameSite=None- 쿠키를 크로스 사이트로 표시하는 데 필요합니다.Secure: HTTPS 사이트에서 설정한 쿠키만 액세스할 수 있도록 합니다.
Firefox 및 Safari에서는 쿠키가 기본적으로 SameSite=None로 설정되며 SSA를 Secure 쿠키로 제한하지 않으므로 이러한 속성이 필요하지 않습니다. SameSite 속성을 명시하고 항상 Secure 쿠키를 사용하는 것이 좋습니다.
최상위 페이지 액세스
Storage Access API는 삽입된 iframe 내에서 서드 파티 쿠키에 액세스할 수 있도록 고안되었습니다.
최상위 페이지에서 서드 파티 쿠키에 액세스해야 하는 다른 사용 사례도 있습니다. 예를 들어 쿠키에 의해 제한된 이미지 또는 스크립트로 인해 사이트 소유자는 iframe이 아닌 최상위 문서에 직접 포함하는 것이 좋습니다. 이 사용 사례를 해결하기 위해 Chrome은 requestStorageAccessFor() 메서드를 추가하는 Storage Access API 확장 프로그램을 제안했습니다.
requestStorageAccessFor() 메서드
requestStorageAccessFor() 메서드는 requestStorageAccess()와 비슷한 방식으로 작동하지만, 최상위 리소스에 사용됩니다. 서드 파티 쿠키에 대한 일반적인 액세스 권한을 부여하지 않도록 관련 웹사이트 세트 내 사이트에만 사용할 수 있습니다.
requestStorageAccessFor() 사용 방법에 관한 자세한 내용은 관련 웹사이트 세트: 개발자 가이드를 참고하세요.
top-level-storage-access 권한 쿼리
브라우저 지원
- 119
- 119
- x
- x
storage-access 권한과 마찬가지로 requestStorageAccessFor()에 액세스 권한을 부여할 수 있는지 확인하기 위한 top-level-storage-access 권한이 있습니다.
Storage Access API는 RWS와 함께 사용할 때 어떻게 다른가요?
관련 웹사이트 세트를 Storage Access API와 함께 사용하면 다음 표에 설명된 대로 특정 추가 기능을 사용할 수 있습니다.
| RWS 제외 | RWS 사용 | |
|---|---|---|
| 저장소 액세스 요청을 시작하려면 사용자 동작이 필요합니다. | ||
| 액세스 권한을 부여하기 전에 사용자가 최상위 컨텍스트에서 요청된 스토리지 출처를 방문해야 합니다. | ||
| 최초 사용자 메시지를 건너뛸 수 있음 | ||
이전에 액세스 권한이 부여된 경우 requestStorageAccess를 호출할 필요가 없습니다. |
||
| 관련 웹사이트 사이트에 다른 도메인에 자동으로 액세스 권한 부여 | ||
최상위 페이지 액세스 requestStorageAccessFor 지원 |
데모: 쿠키 설정 및 액세스
다음 데모는 데모의 첫 번째 화면에서 직접 설정한 쿠키를 데모의 두 번째 사이트에 삽입된 프레임에서 액세스하는 방법을 보여줍니다.
storage-access-api-demo.glitch.me
데모를 사용하려면 서드 파티 쿠키가 사용 중지된 브라우저가 필요합니다.
chrome://flags/#test-third-party-cookie-phaseout플래그가 설정되고 브라우저가 다시 시작된 Chrome 118 이상- Firefox
- Safari
자료
- 사양을 읽거나 문제를 제기합니다.
- API 문서 및 가이드
- 관련 웹사이트 세트에서 Storage Access API를 사용하는 방법에 관한 Chrome 문서