This specification defines a [[!CSP11]] extension to the [[!appmanifest]] specification.

Implementors need to be aware that this specification is extremely unstable. Implementors who are not taking part in the discussions will find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation phase should join the aforementioned mailing lists, or subscribe to the repository on GitHub, and take part in the discussions.

Usage Examples

This section shows how developers can make use of the various features of this specification.

Example - restrictive CSP policy

The following policy allows fetching images, scripts, and CSS from the same origin. It blocks everything else. 

{
  "name": "Super Racer 2000",
  "csp": "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'",
  "start_url": "/start.html",
  "display": "fullscreen",
  "orientation": "landscape"
}

Common conventions and dependencies

The [[\GetOwnProperty]] operation, and the Type(x) notation are defined in [[!ECMASCRIPT]]. Processing also relies on various algorithms defined in [[!HTML]], [[!FETCH]], and [[!URL]].

When instructed to Trim(x), a user agent MUST behave as if [[!ECMASCRIPT]]'s String.prototype.trim() function had been called on the string x.

As the manifest uses the JSON format, this specification relies on the types defined in [[!ECMA-404]] specification: namely object, array, number, string, true, false, and null. Strict type checking is not enforced by this specification. Instead, each member's definition specifies the steps required to process a particular member and what to do when a type does not match what is expected.

The concepts manifest, associated with a manifest, and issue a developer warning are defined in [[!appmanifest]].

Processing the manifest

At the extension point:

  1. Let set of directives be the result of running the steps for processing the csp member.
  2. If set of directives is undefined, then skip this substep:
    1. For any subsequent fetch of a resource that is associated with a manifest manifest, append a header named "Content-Security-Policy" with value set of directives to its response headers.

csp member

The csp member is a string that represents a supplemental security policy. The string is a valid supplemental security policy if it matches the policy-token production defined in [[!CSP11]].

The csp member supplements the policy delivery mechanisms defined in [[!CSP11]], and allows the author to indicate that the user agent is to enforce a supplemental security policy (according to the rules of enforcing multiple policies [[!CSP11]]) for a resource associated with a manifest.

The steps for processing the csp member is given by the following algorithm. The algorithm takes a manifest manifest as an argument, and returns a valid supplemental security policy or undefined.

  1. Let value be the result of calling the [[\GetOwnProperty]] internal method of manifest with argument "csp".
  2. Let type be Type(value).
  3. If type is not "string", and is not undefined, then issue a developer warning that the type of the policy is invalid, and return undefined.
  4. Let set of directives be a set returned by the parse the policy [[!CSP11]] algorithm, that takes value as argument.
  5. If set of directives matches the policy-token production [[!CSP11]], return set of directives, otherwise, issue a developer warning that the policy is invalid and return undefined.

There is only one class of product that can claim conformance to this specification: a user agent.

Use cases and requirements

TBW...

Acknowledgments

This document reuses text from the [[!HTML]] specification, edited by Ian Hickson, as permitted by the license of that specification.