Re: A 'navigation-to' CSP directive

On Fri, Dec 1, 2017 at 6:32 AM, Rob van Eijk <rob@blaeu.com> wrote:

>  However, if an iframe is whitelisted as *child-src*, the [CSP] directive
> would not block the resources the iframe brings in, right? Maybe I
> misunderstood the hierarchy of the 'navigate-to' idea. To help the
> conversation I will provide a use case.
>
> Correct: the parent's CSP generally does not propagate into the child
frame​. Forcing a CSP on another page might itself enable some kinds of
attacks. We are working on an "Embedded Enforcement" spec that does what
you want --if-- the framed site is cooperative. If they aren't cooperative
the frame isn't rendered which means the parent's boundaries are not
violated, but in practice makes it hard to frame 3rd party sites.
https://w3c.github.io/webappsec-csp/embedded/

A third-party API is included on a webpage with an I-frame. The third party
> uses external embedded resources to measure JavaScript errors (
> usage.trackjs.com, js-agent.newrelic.com, bam.nr-data.net). These
> resources should be whitelisted as the are necessary for the functioning of
> the third-party API. However, the third party also includes an analytics
> pixel used for, e.g., purposes that would trigger the consent requirement
> under EU law. It would be great if this pixel could be blocked by the
> webpage owner through CS
>

​"navigate-to" wouldn't prevent an analytics pixel in any case.

-Dan Veditz​