Update explainer to unify storage access permissions and replace CORS with storage access headers #50
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update explainer to unify top-level-storage-access permission with storage-access permission by changing language that references different permissions. Update explainer to replace CORS with storage-access-headers
Remove reference to cors in the example code.
Update link to also have acronym
aselya
changed the title
johannhof
reviewed
Mar 14, 2025
Member
johannhof
left a comment
johannhof
left a comment
There was a problem hiding this comment.
Thanks for the PR, had a couple of thoughts / questions :)
| let img = document.createElement('img'); | ||
| // CORS would be required for the SameSite=None cookies to be attached. | ||
| // SAH would be required for the SameSite=None cookies to be attached. |
Member
There was a problem hiding this comment.
Might be worth spelling out Storage Access Headers here, even if it breaks the line.
| 1. Request permission via the permissions API. | ||
| 1. This would allow implementation-defined acceptance or rejection steps; if any are triggered, reject the requestStorageAccessFor call or skip to the permission-saving step. | ||
| 1. If acceptance is returned, save a permission for the pair `{top-level site, requested origin}`. Note that the permission would be separate from the permission granted by `requestStorageAccess`. | ||
| 1. If acceptance is returned, save a permission for the pair `{top-level site, requested origin}`. Note that the permission would be the same permission granted by `requestStorageAccess`. |
Member
There was a problem hiding this comment.
Hm, I wonder if we even need this proposed draft spec section anymore, now that we have the actual spec. I think I'd be okay with removing it.
@cfredric any strong opinions?
Collaborator
There was a problem hiding this comment.
+1, IMO we should defer to the real spec now that there is one. (On that note, should this PR also modify the spec, so that the spec and explainer stay in sync with each other?)
Similarly, I don't think we need the section below which discusses under which circumstances to attach cookies (and how to modify Fetch), since the Storage Access Headers spec already defines those details in its spec.
| Other potential embeddee opt-in mechanisms, especially for those user agents that do not support Related Website Sets, could include: | ||
|
|
||
| * Specification of a `.well-known` configuration that can be checked to ensure embeddee opt-in. | ||
| * Specification of a `.well-known` configuration or API that can be checked to ensure embeddee opt-in. |
Contributor
Author
There was a problem hiding this comment.
One of the possible solutions that was brought up at TPAC was allowing a site to use an API instead of (or in addition to) a .well-known file. Adding it to the explainer for more visibility.
| * For nested resource loads, [a variant of the site for cookies algorithm](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-10#section-5.2.1) could be used to avoid unrelated iframes from using a grant, potentially with a permission policy opt-out, as suggested in [a recent security analysis](https://github.com/privacycg/storage-access/issues/113). | ||
| * Another alternative would be requiring explicit per-frame opt-in via normal `requestStorageAccess` call; see below. | ||
| * `SameSite=None` cookies granted via `requestStorageAccessFor` on subresources should only be attached on CORS-enabled requests. For example, an `<img>` without a [`crossorigin` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/crossorigin) set to `use-credentials` would not have `SameSite=None` cookies attached, even with a valid grant. This ensures the server is aware of the caller and can react accordingly; because the response must have the appropriate header to be read by the embedder, this ensures the embeddee has opted in. Note that CORS is not possible on navigations; this requirement is not intended to protect `<iframe>` elements. | ||
| * `SameSite=None` cookies granted via `requestStorageAccessFor` on subresources should only be attached on requests that include the header `Sec-Fetch-Storage-Access: active`. For example, an `<img>` without a [`crossorigin` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/crossorigin) set to `use-credentials` would not have `SameSite=None` cookies attached, even with a valid grant. This ensures the server is aware of the caller and can react accordingly; because the response must have the appropriate header to be read by the embedder, this ensures the embeddee has opted in. |
Member
There was a problem hiding this comment.
I think you'd need to change more of this sentence, the <img> example now also seems unrelated.
I kind of feel like we could remove a lot here and mostly point to the existing security protections for the storage access API, given that this would reuse its permission.
| #### CSRF Considerations | ||
|
|
||
| A side effect of disabling `SameSite=None` cookies is that attacks like CSRF become significantly harder to carry out. While the existing `requestStorageAccess` API already allows a mechanism to opt a specific frame out of this protection, `requestStorageAccessFor` could be used more broadly due to its relaxation of the `<iframe>` requirement. Additionally, `requestStorageAccessFor` is invoked by the embedder, as opposed to the embedded origin which gets access to cross-site cookies. This makes additional opt-in requirements for embedded resources, like those described above, more attractive. Note that the suggested CORS requirement would not block cookies from being sent other than on pre-flighted requests, though causing such cookies to be sent could also potentially be done via opening popups or triggering other navigations, reducing the concern. | ||
| A side effect of disabling `SameSite=None` cookies is that attacks like CSRF become significantly harder to carry out. While the existing `requestStorageAccess` API already allows a mechanism to opt a specific frame out of this protection, `requestStorageAccessFor` could be used more broadly due to its relaxation of the `<iframe>` requirement. Additionally, `requestStorageAccessFor` is invoked by the embedder, as opposed to the embedded origin which gets access to cross-site cookies. This makes additional opt-in requirements for embedded resources, like those described above, more attractive. |
Member
There was a problem hiding this comment.
This whole section can probably be removed?
Co-authored-by: Johann Hofmann <mail@johann-hofmann.com>
Co-authored-by: Johann Hofmann <mail@johann-hofmann.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update explainer to describe the unification of the
top-level-storage-accessandstorage-accesspermissions and the replacement of CORS with Storage Access Headers as the security mechanism for the API.