Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Setting policy when origins are not known ahead of time #24

Closed
sandinmyjoints opened this issue Oct 25, 2015 · 5 comments
Closed

Setting policy when origins are not known ahead of time #24

sandinmyjoints opened this issue Oct 25, 2015 · 5 comments
Milestone
Future

Comments

@sandinmyjoints
Copy link

As suggested here, I'm opening an issue to describe a problem we've run into that prevents us from using sandbox on iframes.

In short, we run ads, and ads create iframes programatically. We don't know ahead of time where those iframes will be hosted. It'd be great to have a way of specifying a policy to apply to all cross-origin iframes.

I wrote up the problem more fully here: http://williambert.online/2015/10/How-HTML5-sandboxes-could-be-so-much-more-useful/

I confess to not reading the draft spec in its entirety, but I did find something that looks related to this in the Source Lists definition. The definition of host-part includes *. Would this allow me to write a CSP that applies sandboxing restrictions (including any allow flags that I choose to use) to any iframes created on my page from any and all origins?
@sandinmyjoints
Copy link
Author

After reading #12, I now understand better the story behind https://mikewest.github.io/csp-embedded-enforcement/ My question with embedded enforcement is the same: can I apply it broadly without knowing origins ahead of time?

@mikewest
Copy link
Member

mikewest commented May 9, 2017

We're (finally) getting closer to shipping something like https://w3c.github.io/webappsec-csp/embedded/ in Chrome. Perhaps you could skim that doc to see if it suits your needs?

@mikewest mikewest added this to the Future milestone May 9, 2017
@sandinmyjoints
Copy link
Author

sandinmyjoints commented May 10, 2017 •
edited
Loading

Thanks for the pointer @mikewest. From skimming it, it sounds like the use cases I am talking about are not covered. The problem in a nutshell is that we, the content publisher, cannot know embedded content origins ahead of time. This is the nature of the ad marketplace in 2017. There are thousands of possible origins, and they change frequently. The libs we load from our ad partners create the iframes, or load other code that create the iframes, and so it goes.

What we need is a template, a way of saying "for all cross-origin iframes that are going to be created, apply the following sandbox rules (eg, the new allow-top-navigation-by-user-activation which would be very useful for us!) Maybe something like <html iframe-sandbox-template="allow-top-navigation-by-user-activation allow-script allow-same-origin allow-forms">. Does that make sense?

@Malvoz
Copy link

Malvoz commented Aug 1, 2019

This may be solved by the Require-Document-Policy HTTP header defined in Document Policies :)

@sandinmyjoints
Copy link
Author

Thanks, @Malvoz -- that does look promising for solving this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Future
Development

No branches or pull requests
3 participants
@mikewest @sandinmyjoints @Malvoz