Content Security Policy: Cookie Controls

1. Introduction

This section is not normative.

Cookies are an HTTP state management mechanism that web developers rely on heavily for important things like authentication. They are also quite fragile, and have scoping rules that don’t mesh well with the origin model that developers are familiar with. Cookies flow freely between schemes by default, can be set from subdomains or limited to paths, and ignore ports entirely. The disconnect between cookies and other types of storage opens up a number of risks that are difficult to fully mitigate. See [YUMMY-COOKIES] for some real-world examples of problems that have cropped up in the past.

This document defines mechanisms which allow developers to limit the ways in which cookies can be set for a given protected resource.

1.1. Examples

Content-Security-Policy: cookie-scope none

Content-Security-Policy: cookie-scope host

document.cookie = "key=value";

document.cookie = "key=value; domain=example.com";

Content-Security-Policy: cookie-scope host secure

document.cookie = "key=value; secure";

document.cookie = "key=value";
document.cookie = "key=value; domain=example.com; secure";

2. The cookie-scope directive

cookie-scope is a Content Security Policy directive [CSP] which restricts the cookies [RFC6265] which can be set in a particular context. The syntax is described by the following ABNF grammar [RFC5234] (including the RWS rule from [RFC7230]):

directive-name = "cookie-scope"
directive-value = scoping-rules *( RWS scoping-rules )
scoping-rules = "host" / "http" / "none" / "secure"

The directive has one of four values:

1. "host" allows "host only" cookies to be set, but will block setting cookies which set a domain attribute.

2. "http" allows cookies to be set via the Set-Cookie HTTP header, but not via document.cookie.

3. "none" blocks all cookies.

4. "secure" allows cookies to be set with a secure attribute, and will block setting any non-secure cookies.

These values MAY be combined in order to tighten the restrictions on a cookie. That is, if both "host" and "secure" are present, then cookies may only be set which are both secure and host-only. If "none" is present with any combination of the other values, no cookies may be set.

Erik Nygren proposed adding path restrictions as well. Is that worthwhile?

2.1. Processing Model

After step 10 of the storage algorithm in Section 5.3 of RFC 6265, a cookie object has been built. Insert the following validation step before proceeding to the current step 11:

11. If §3.1 Is cookie blocked for settings? returns "Blocked" when executed upon cookie and the incumbent settings object, abort these steps without modifying the cookie store.

Monkey patching! Hey, maybe it’s time to reopen that cookie RFC after all, eh @mnot? :)

We’ll need a mechanism to restrict reading from document.cookie, but I’d like something less specific than cookie-scope disable-dom-access or something similar. The linked GitHub bug is a proposal that’s a bit more general and widely applicable. <https://github.com/w3c/webappsec-csp/issues/42>

3. Algorithms

3.1. Is cookie blocked for settings?

Given a cookie (cookie), and an environment settings object (settings), this algorithm returns "Allowed" if cookie can be written, and "Blocked" if it violates one or more of settings’s enforced Content Security Policies:

1. Let status be "Allowed".

2. For each policy in settings’s monitored Content Security Policies:

   1. If §3.2 Does cookie violate policy? returns "Violates" when executed upon the cookie and policy, report a violation.

      Note: We do not touch status here, as we’re only evaluating the monitored policies.

3. For each policy in settings’s enforced Content Security Policies:

   1. If §3.2 Does cookie violate policy? returns "Violates" when executed upon the cookie and policy, report a violation, and set status to "Blocked":

4. Return status.

3.2. Does cookie violate policy?

1. Let scope be the result of executing §3.3 Parse string as a cookie-scope value on policy’s cookie-scope directive.

2. If any of the following conditions are met, return "Violates":

   1. scope contains "host", and the cookie’s host-only-flag is false.

   2. scope contains "http", and the cookie was received from a "non-HTTP" API.

   3. scope contains "none".

   4. scope contains "secure", and the cookie’s secure-only-flag is false.

3. Return "Does not violate".

3.3. Parse string as a cookie-scope value

Given a string (string), this algorithm returns a set of the valid cookie-scope values the string represents. Invalid values are ignored:

1. Strip leading and trailing whitespace from string.

2. Let values be an empty set.

3. For each token in the list generated by splitting string on spaces:

   1. If token matches the grammar for scoping-rules, insert token into values.

4. Return values.

4. Security Considerations

4.1. Existing Cookies

Note that the mechanisms defined here do not protect against cookies that already exist in a user’s cookie store. Those cookies are delivered along with the HTTP request, before Content Security Policy can be delivered and applied. It is possible that future work like [CSP-PINNING] might enable these kinds of a priori restrictions, but, even then, CSP should be seen as a mitigation strategy, layered on top of filters and sanity checks for incoming data.

5. Acknowledgements

Mark Nottingham proposed this directive several years ago. Sorry it took so long, Mark!