Feature: CSP should allow simultaneous `Content-Security-Policy-Report-Only` and `Content-Security-Policy-Report-Only`

[thernstig]

Currently an option exists to allow only reporting of violations:

options.reportOnly is a boolean, defaulting to false. If true, the Content-Security-Policy-Report-Only header will be set instead.

But according to https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#testing_your_policy it should be allowed to include both a Content-Security-Policy and Content-Security-Policy-Report-Only header.

Usage scenario
Let's say you have a current CSP policy, but want to evaluate a new, future policy. This means you want to continue using the one you already enforce, but at the same time evaluate the new one. Read more at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only

I think this in turn should remove options.reportOnly in a new major release. Users would instead get full functionality via:

app.use(
  helmet.contentSecurityPolicy({
    policy: {
      directives: {
        "script-src": ["'self'", "example.com"],
      },
    },
    reportPolicy: {
      directives: { // or reportPolicy
        "script-src": ["'self'", "example.com", "lolcat.com"],
      },
    },
  })
);

Unfortunately this means the top-level properties needs to be moved into a policy and reportPolicy property. This is to allow options such as options.useDefaults to be set per header.

[EvanHahn]

This is an interesting idea and one I'll keep in mind. It's possible that we could add this without a breaking change, which I'll have to think about.

Here's one way you could do this with Helmet today:

app.use(
  helmet.contentSecurityPolicy({
    reportOnly: false,
    directives: {
      /* ... */
    },
  })
);

app.use(
  helmet.contentSecurityPolicy({
    reportOnly: true,
    directives: {
      /* ... */
    },
  })
);

Would something like this work for you?

[thernstig]

That is interesting, was not aware that works. That is good info.

From an API standpoint I think the initially proposed solution is the most elegant one. Of course carefully contemplating this before doing anything is good.

[EvanHahn]

After some consideration, I don't think I'm going to add this to Helmet for three reasons:

1. I don't want to increase Helmet's surface area if I can help it.
2. I don't think this is a very common use case. I'm sure you're not the only one to want this, but this isn't a common feature request.
3. The workaround is, in my opinion, straightforward.

We'd have to document the new feature anyway. Why not just document the workaround instead? I've added a note to the documentation (see 7848f5a) to make this more obvious for people in the future.

I'm going to close this issue because I think it's resolved, but let me know if you disagree.

[thernstig]

@EvanHahn documentation it makes perfect sense, and I do think the workaround is good as-is. Thanks for a great project.

[amochuko]

Hi @EvanHahn
I learnt CSP report-uri is deprecated https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/report-uri and instead to use report-to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/report-to

I couldn't find such interface implemented in helmetJS when I wanted using it. So I was thinking if it's wise extending interface ContentSecurityPolicyOptions or better still; please, direct a resolve for me.

Thanks.

[EvanHahn]

@iamochuko You should be able to use the report-to directive like this:

app.use(
  helmet.contentSecurityPolicy({
    directives: {
      // ...
      "report-to": ["groupname"],
    },
  })
);

Please open a new issue if you run into problems.

[amochuko]

@EvanHahn I will give it a go once I return to my station. Thanks

[TimShilov]

@EvanHahn I just stumbled on this issue looking for ways to use both headers at the same time.

First of all, I don't believe the workaround is still in documentation.

Also, I'd like to challenge the idea that having it as a feature in helmet is not a good idea.
Here are a few thoughts:
It can raise awareness
You've mentioned that this is not a common feature request, but I won't be surprised if the reason for that is - a lot of people simply aren't aware that both headers can be used in together because helmet makes them seem exclusive.
I've heard from developers on my team "this is a boolean flag in helmet so if we want reporting - we'd have to disable CSP". Given that, I believe that not having first-class support for both actually hurts security as I'm willing to bet there are people who actually do disable CSP to test changes before enforcing them and helmet is greatly placed to improve that.

It can improve the common workflows
I'd argue that everybody should use both Content-Security-Policy and Content-Security-Policy-Report-Only, as IMO that's the only way to make CSP actually flexible and maintainable long-term.
Having to search GitHub issues and implement workarounds IMO hurts the adoption of this arguably good workflow. If something is not implemented as a first-class feature it begins to look like "hack" and repels people.

[EvanHahn]

@TimShilov I've been thinking about your comment and I now think you're right.

Do you (or anyone else) have suggestions for a backwards-compatible API that lets people set two sets of directives?

[thernstig]

Would this not work?

app.use(
  helmet({
    contentSecurityPolicy: {
      directives: {
        "script-src": ["'self'", "example.com"],
      },
    },
    contentSecurityPolicyReportOnly: {
      directives: {
        "script-src": ["'self'"],
      },
    },
  }),
);

That would ignore any reportOnly set.

Another option would be similar to the OP where you have two subproperties under contentSecurityPolicy that when set ignores the other top-level directives.