Let's define the correct technical terms and dispel some myths CSP about.
- Content Security Policy doesn't care about "active" or "interactive" content.
script.js file (except Firefox, in case of workers).
logo.gif with "image/png" MIME a "passive" content? Not at all (hello from polyglot GIF with built-in JS). But browsers ignore any CSP header send with such
logo.gif file, CSP have no deal with that.
Is the mp3 an "interactive" content"? You can interact with that - to press stop/pause/loud/rewind, but CSP headers sent with MP3/MP4 file doesn't block it play.
In parallel, is dispelled the second myth that MIME type have a meaning. Due to sniffing, browsers examine real files format and ignore MIME in most cases.
There is not any "passive" content for browsers. Browsers render all content as HTML and apply CSP sent with any file. Open this robots.txt in Chrome and check browser console - you'll see that CSP blocks inline styles. Right mouse click -> "Inspect code" and you'll see an artificial HTML wrapper.
So what is governed by CSP and where does it work?
A security model under which CSP operates is based on origins and browsing contexts (as and a security model of Same Origin Policy).
Therefore, it only makes sense to publish Content Security Policy for a separate browsing context.
The top-level document creates a top-level browsing context, and
<embed> tags create nested browsing contexts.
If you embed an image as
<img src='logo.gif'> a separate browsing context is not created, therefore such image falls under CSP of embedding context.
If you embed an image as
<iframe src='logo.gif'> a separate browsing context is created therefore such image can have own CSP header.
Note 1 that some browsing contexts can be non-isolated from point of view of CSP, and will inherits CSP of parent context.
Note 2 A
frame-ancestors is the only directive that does not affect the viewing context that issued the CSP, but affects all its parent contexts. Arminius in his answer revealed the specifics of this directive including for non-HTML files.
Now topic starter can answered his questions byself:
Redirect response (redirect 302)
does not create a browsing context so CSP is not supported creates a nested browsing context, therefore CSP header is applicable (Google publishes CSP on accounts.google.com page with redirect 302). Keep in mind that CSP have a deal with redirects, for instance in
form-action directive. But behaviour is different in Chrome and Firefox.
Non HTML response (json, css, etc...)
Such responses be handled by parent HTML document (browsing context), therefore CSP header of sub-responses will be ignored (except script loaded for SharedWorkers in Firefox). But origins of request to get such responses is covered by CSP of this parent document.
If you open such "non HTML response" directly in address bar (separate browsing context), the CSP sent will apply but there is no reason to protect this context. Only parent page with the same origin can access such arctificially created HTML wrapper (maybe browser extensions can access too).
And now - a question for $1000: Do I need to publish CSP on pages with response codes 4xx and 5xx (Not Found and Internal Server Error, etc)?
Safety is never enough...