预告片标头中的 Content-Security-Policy 标头不起作用

Question

I setup a simple nodejs http-server that stream-processes an html request. As the html is streamed, it extracts any inline content into a seperate element and calculates its hashes. In the final step, a trailer-header is senc containing the original csp + the new hashes.

However, the browser (all: Chrome, Firefox, Edge) does not honour the csp!

The above in pseudo-code (node-js like):

const server = http.createServer((reqest, response) => {
    response.setHeader('Transfer-Encoding', 'chunked');
    response.setHeader('content-type', 'text/html');
    response.setHeader('Trailer', 'content-security-policy');
    const stream = getHTMLSAXStream();
    stream.on('data', function(element) {
        // extract inlines and save, e.g. styles.push(element.style);
        // then remove the attr: e.g. element.style = undefined;
        // then on the stripped html: e.g. response.write(element.toHTML())
    });
    stream.on('end', function() {
        const stylefile= `${styles.join("\n")}`;
        const url = getUrlForString(stylefile); // make this file available on a temporary url
        response.write(`<link rel="stylesheet" href="${url}">`)
        response.addTrailers({ 'content-security-policy': mergeWithDefaultCSP("style-src: sha256-${sha256(stylefile)}") });
        response.end(); // send response
    })

As per MDN docs on trailers some headers are disallowed, however couldn't find a reason why the content-security-policy shouldn't be allowed. More specifically, as per trailer header and csp spec :

A sender MUST NOT generate a trailer that contains a field necessary for message framing (eg, Transfer-Encoding and Content-Length), routing (eg, Host), request modifiers (eg, controls and conditionals in Section 5 of [RFC7231]), authentication (eg, see [RFC7235] and [RFC6265]), response control data (eg, see Section 7.1 of [RFC7231]), or determining how to process the payload (eg, Content-Encoding, Content-Type, Content-Range, and Trailer).

The CSP is not used for message framing, it is not used for routing, it is not used as a request modifier, not used for authentication and isn't used for processing the payload (only used after processing the payload, aka the html) - in short, I don't see a reason it shouldn't work!

Does anyone know more? Have I missed anything?

To get around this, currently I'm using the following workaround (I'd like to get rid of):

• don't use hashes, whitelist by domain (eg all scripts are coming from the same domain)
• use nounces instead of hashes (won't play well with cdns though)

More on the background, why am I doing this at all: I have a cms that allows using raw html (incl. inline-styles and script tags) which I frequently use (else I'd need to deploy again, etc etc). On the other hand I'd like a good working CSP (eg when user-generated comments are loaded onto the page from an api with javascript (not in the backend, that would defeat the purpose!), just in case. Therefore I'd like to allow only my own inline-style and script tags, but no-others. The above addresses this adequatly.

Answer 1

No matter what the spec says, it's up to browsers to support this and last I header browser support for trailing headers is very limited: Do any browsers support trailers sent in chunked encoding responses?

Additionally I don't think it makes sense for CSP for two reasons:

1. HTML is often streamed (as you state you are doing) and the browser will render as the HTML comes in. To then retrospectively apply the CSP to already rendered content would be pointless - the damage has been done.

2. Multiple CSPs are additive and not replacing. Ie it the most restrictive CSP that matters. So if you've a basic CSP and then want to add a nonce that is not possible AFAIK.