For my own clarity, you're serving an HTML document (let's say `https://example.com/`) with the policy `default-src 'self'; style-src 'self'; frame-src 'self' data:`, and including a `data:` frame in that document?

In that case, we copy the parent page's policy down to the child frame and apply it there. In that case, `'self'` is no longer referring to `https://example.com/`, but to `data:...`, and therefore isn't going to match anything.

I'm pretty sure this matches the specced behavior. What would you expect it to do instead? (It might be worth opening a spec issue at <https://github.com/w3c/webappsec-csp/issues>).

In my understanding, if the parent's policy is copied to its child, the `self` should refer to the parent, not to `data:`, for the following reasons:

1) If you do propagate a policy down to children, they are obviously under the parent's control, so the policy, including the `self`, should have the same meaning as deemed by the parent. In contrast, if a child has its own policy, e.g. `src="third-party.com"`, the parent obviously has nothing to do with it, which gives birth to the child's `self`. In other words, the `self` represents the document that has declared the policy, not any other that happened to inherit it.

2) Both CSP header and `<iframe src="data:">` are managed by the document owner, so they are sharing the same context. You know what exactly the `data:` contains, so you reflect this in the CSP.

3) `self` being `data:` is not making much sense either. This forces all resources to be `data:` as well, not loaded from the parent's domain. In my case, the CSS has to be data-encoded, to be encoded again as part of the iframe's `data:`.