Allow enforced CSP and Report-Only at the same time

[qll]

The CSP 1.0 specification allows this explicitly in the sixth paragraph of Section 3.3: http://www.w3.org/TR/CSP/#processing-model
An example is given, too: "For example, if a server operator is using one policy but wishes to experiment with a stricter policy, the server operator can monitor the stricter policy while enforcing the original policy."

This would require bigger changes to the way the middleware works (maybe a flag as a parameter to the decorators? ... something like only_report=True). If this is in scope for the middleware, I am willing to propose an implementation soon.

[jsocol]

Definitely in scope, would be happy to support this, but it is going to require a big change, at least in terms of API, we should figure out how we want it to look first. Tagging in @graingert and @mozfreddyb.

One option would be to add a second, parallel set of settings, e.g.:

CSP_DEFAULT_SRC = '...'
CSP_RO_DEFAULT_SRC = '...'
CSP_IMG_SRC = '...'
CSP_RO_IMG_SRC = '...'

Then utils.from_settings would either need a companion (and probably a re-name) or a lot more complexity. The CSP_REPORT_ONLY boolean could still be used to flip the normal settings (i.e. without _RO) to report-only mode, or users could just define the _RO settings instead.

It's verbose, I don't love it. The decorator would still need a keyword to decide which policy is being updated (or both?). But it is a way to do site-wide alternate policies. Doing that via decorator would be painful.

Maybe instead of x number of settings, it makes sense to change it to one setting in a dict, in the style of other complex Django settings? e.g.

CSP_POLICY = {
    'default': {
        'DEFAULT_SRC': "'self'",
        'IMG_SRC': ["'self'", 'img-host.example.com'],
        'REPORT_ONLY': False,
    },
    'test_new_policy': {
        ...,
        'REPORT_ONLY': True,
    }
}

# Optional setting, defaults to 'default'
CSP_POLICIES = ['default', 'test_new_policy']

It's a bigger API change, but maybe lets things be cleaner when building policies? And it condenses, rather than expands, the namespace.

Alternate proposals?

[graingert]

I think you want two policy dicts so as to reflect how the underlying headers operate:

CSP_REPORT_ONLY_POLICY = {
    'DEFAULT_SRC': "'*'",
}
CSP_POLICY = {
     'DEFAULT_SRC': "'self'",
}

[jsocol]

CSP technically does allow multiple policies. Not sure exactly why you'd want to, but allowing n>=1 policy definitions is more in line with that part of the spec.

[graingert]

In that case something like:

CSP_POLICIES = [
        {
            'DEFAULT_SRC': "'*'",
        },
        {
             'DEFAULT_SRC': "'self'",
             'REPORT_ONLY': True
        }
]

Rather than using a dict and defining order in another setting

[graingert]

Also the CSP specification is invalid according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.

[jsocol]

There is no precedent for an ordered list of dicts in the django settings. A dict allows these to be named, and a separate setting makes it easy to flip them on and off or reorder.

[jsocol]

It's not our job here to resolve issues between RFC2616 and CSP.

[mozfreddyb]

I like @jsocol's original proposal, even though it is a bit verbose, but I prefer explicitly here.
It would need some work for current users of django-csp, but there's little we can do?!

[qll]

Yep, I like the nested dict idea, too. However, why use "DEFAULT_SRC" rather than "default-src"? The latter would copy the original header more closely.

[jsocol]

@mozfreddyb do you mean a nested dict or a parallel set of settings?

@qll copying the style of other settings (e.g. DATABASES and CACHES) but you're right, in this case copying the names directly from the header is a more compelling way to do it.

[mozfreddyb]

Nested dict as in your very first comment, @jsocol.

[DylanYoung]

Love the nested dict idea. You should add support to the decorators as well to replace or append policies based on name.

Knowing that there is support in the spec for multiple policies makes me question whether the CSP decorator (@csp) is adequately clear and explicit? It could be append CSP or replace CSP. I'd suggest clearing the existing CSP should be done through one and only one very clear path (@csp_exempt) to avoid user error in a security-critical component of the app (I would rename this: @csp_clear or @csp_purge for clarity).

Does it also make sense to think about plugging into the sites contrib app to allow per site CSP configurations in the DB? (for now, this could be name-based and hardcoded in settings, but eventually dynamic db-based CSPs could be supported...)

And finally a thought on backwards compatibility for users:

You can leave the current settings, just load them into the policy dict under the 'default' key. If the 'default' key is also explicitly defined, throw an error. Set CSP_POLICIES to ['default'] by default ;)

[DylanYoung]

Oh and this issue is super old. Would you like me to take this on?

[EnTeQuAk]

@DylanYoung if you have the time for it, please go for it.

Regarding what you said...

(I would rename this: @csp_clear or @csp_purge for clarity).

Personally, I don't think that's necessary. @...except follows various Django APIs and should be explicit enough imho.

I also don't think we need support for django.contrib.sites - I'd leave that to specific projects to handle dynamically. We shouldn't solve all problems in this library, that'd be out of scope.

Yeah, I like your idea of backwards compatibility. We could first introduce the new policy dictionary but also allow loading of it, if it's specified. That way we can safely deprecate old settings and transition to the new settings format.

Looking forward to reviewing your pull request!