New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 685453 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Provide FeaurePolicy or CSP directive to limit frame tree access

Project Member Reported by ojan@chromium.org, Jan 26 2017

Issue description

We've heard demand from some 3rd party providers that they would like to limit the access of two same-origin with each other but cross-origin with the parent page frames. For example, two ads from the same ad network can muck with each other's contents. Instead, they would like the pages to behave as if they were cross-origin with each other (i.e. they just have postMessage).

They can't use sandbox because they need the pages to actually be on that origin. For example, they need XHRs to work. 
 
We might be able to do something like this by setting the domain property of the document to something opaque (and, I presume, not allowing it to be further modified by the document).

By "same-origin with each other but cross-origin with the parent page": is the sibling relationship, with a cross-origin parent, relevant to this, or is this something that should be possible with any frame? Should the parent page be able to include a same-origin iframe, but isolate it in this way so that it is effectively treated as cross-origin?

Comment 2 by mkwst@chromium.org, Jan 26 2017

It would be helpful to better understand in what sense folks would like the two pages to act as cross-origin with each other. You note that XHR to the server should still work, for example.

We've done some work in this space for Suborigins (https://w3c.github.io/webappsec-suborigins/) that seems relevant, creating a number of axes along which a page can segregate itself from its origin. Are some/all of those what you're hearing about here? Or is the request more narrow: would blocking DOM access be "enough"?

Comment 3 by ojan@chromium.org, Feb 24 2017

Here's the use case: top-level page at toppage.com. Subframes at ads.com. The ads contain arbitrary HTML provided by advertisers, so ads.com doesn't trust them. They'd like the two ads.com subframes to only be able to talk to each other via postMessage and the other limited set of methods available if you have a handle on a cross-origin frame so that one ad can't read the contents of another ad.

Does suborigins address that? It seems like it might, but I had trouble wrapping my head around it. Is there an explainer that has examples without all the surrounding specese and TODOs? Also, what's the status of suborigins work?
Project Member

Comment 4 by sheriffbot@chromium.org, Mar 7 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment