Version: 0.1 | 0.2 | 1.0 | 2.0 (cur)

Please note this is not a specification document. This is one proposal for the syntax and delivery for Site Security Policy. Discussion is open to all interested parties. We hope that a working spec which can be implemented by all browsers is one of the byproducts of this discussion.

Also, it seems appropriate to acknowledge RSnake and Gerv who originated this idea. Jeremiah Grossman has also been extremely helpful in advancing it.

Policy Focus

We identify four security policy areas that website administrators can choose to define. Each area is optional and can be defined independently from the other areas. Security policy can be defined on a per-resource basis and can vary according to the sensitivity of a particular resource. Additionally, a reporting server can be specified as part of a server's security policy which tells the browser where to send reports when JavaScript or a cross-site request was blocked per some security policy. This has the added benefit of showing a website admin which pages within their site are being actively attacked or are potentially misconfigured.

  1. Script-Source
    • Script-Source instructions returned by the server indicate a (potentially empty) set of domains that should be treated as valid sources of JavaScript for the page.
    • When any Script-Source instruction is received by the browser script enforcement mode is enabled and only white-listed hosts will be treated as valid sources of script for the page. Any script embedded within the page and any script included from non-white-listed hosts will not be executed.
    • In the absence of any Script-Source instructions, all JavaScript for a particular resource including embedded, inline, and external will be treated as valid and executed by the browser as normal.
    • Script-Source instructions are sent as HTTP response headers and are used by the browser to determine the JavaScript behavior for the corresponding page. Note the difference between this model and the model used by Request-Source instructions below.
  2. Request-Source
    • Request-Source instructions sent by the server indicate a (potentially empty) set of domains whose content should be allowed to request the resource.
    • In the absence of any Request-Source instructions, content from all sites will be allowed to initiate requests to the corresponding resource. Note that this keeps the prevention of CSRF primarily as the responsibility of the server receiving the cross-site requests. A supporting browser will make the preemptive policy check before sending content-initiated cross-site requests, but those requests will only be blocked if a Request-Source deny rule matching the requesting domain is returned.
    • A policy query will be made by the browser before a cross-site request is initiated by page content. Requests made via non-safe HTTP methods will not be sent if they violate a site's security policy.
    • These instructions take precedence over any Request-Target instructions which are defined below.
    • Security policy for a particular resource can be cached for some period of time per the server's instructions. The policy cache will expire at the end of the browser session.
  3. Request-Target
    • Request-Target instructions returned by the server indicate a (potentially empty) set of hosts which should be white-listed by the browser as valid targets for cross-site requests initiated by the page's content.
    • Request-Target instructions provide a way to prevent page content from making outbound communication to other sites. This prevents data from being exfiltrated from the site as well as preventing additional non-intended resources from being included in the page.
    • Request-Target instructions can also be used to restrict a website from being used as a platform to attack other websites via CSRF. These may be particularly useful for sites that permit users to post HTML and JavaScript in publicly accessible areas.
    • Security policy for a particular resource can be cached for some period of time per the server's instructions. The policy cache will expire at the end of the browser session.
  4. Report-URI
    • The Report-URI instruction tells the browser where to send reports when Site Security Policy prevents JavaScript from executing or page content from initiating a cross-site request.
    • A report will consist of a POST made to the specified URI containing as the POST body the full HTTP request which led to the policy violation.
    • For a page resulting in multiple policy violations, the browser will not send duplicate reports for a single page view.
    • This policy is not cached and will be expired immediately by the browser. Note that the server will need to send a Report-URI instruction explicitly with each page for which it wants policy violation feedback.

Syntax and Delivery

Site Security Policy is delivered to the browser via custom HTTP headers. As indicated above, these policy headers will fall into two general groups. The first group consists of direct or inline policy, intended by the server to be applied as processing instructions for the attached content. The second group consists of third-party policy which is sent in response to specific policy queries. In these cases the server provides information which allows the client to decide whether or not to allow a content-initiated request to another site. A similar model is described in the W3's Access Control specification. Much of the policy described below makes reference to host items since Site Security Policy applies levels of privilege to page content based on its originating host. A host item is a domain string which may contain wildcards (*) which is explicitly allowed or denied in each instruction. Internationalized domain names are specified according to their punycode representations. Returned resources may contain one or more policy instructions defined. The instructions can be combined into one set and any conflict within a set of instructions will be resolved by following the more restrictive policy.

  1. Script-Source
    • A valid Script-Source instruction contains one or more pairs of the form ("allow or deny", "host item").
    • Example: X-SSP-Script-Source: allow *.example.com; deny public.example.com
  2. Request-Source
    • Request-Source instructions are sent in response to policy queries made by the browser before allowing page content to make a cross-site request. The policy query sent by the browser is a HEAD request to the cross-site resource containing the HTTP header Policy-Query:. The policy instructions sent by the server in response to this query consist of one or more triplets of the form ("allow or deny", "host item", "list of HTTP methods") and an optional expires attribute specifying the number of seconds to cache the policy. The following are examples of valid Request-Source instructions:
    • X-SSP-Request-Source: deny * post; allow * get; expires 60
    • X-SSP-Request-Source: allow *.example.com post,get; deny public.example.com *; expires 3600
  3. Request-Target
    • A valid Request-Target instruction contains one or more triplets of the form ("allow or deny", "host item", "list of HTTP methods").
    • Example: X-SSP-Request-Target: allow *.example.com *, deny public.example.com post
  4. Report-URI
    • A report URI instruction contains the URI to which the browser should POST the full request which resulted in the policy violation.
    • Example: X-SSP-Report-URI: http://www.example.com/policy.cgi

Conclusions

Site Security Policy provides a way to greatly reduce or altogether eliminate a website's attack surface for Cross-Site Scripting. With proper Site Security Policy in place, a successful XSS attack will require the attacker to have control over the contents of white-listed script source files. No longer will XSS attacks which rely on echoing script into page contents be effective. Further, if a site knows it never want to have JavaScript executing in its pages, it can simply globally disable JavaScript and not have to worry about script injection attacks against its users with supporting browsers.

Site Security Policy also provides a simple way for a website to prevent Cross-Site Request Forgery against its sensitive resources. A comprehensive CSRF protection mechanism, such as form token checking, can be complicated to implement and difficult to integrate into an existing web application. Such a mechanism may even be subject to its own security bugs. Even a properly implemented CSRF-protection-token system will not stand up in an environment with XSS bugs. Web sites facing these challenges can utilize Site Security Policy to harden themselves against attack and achieve a higher level of confidence in the security of their systems with an added layer of security. Websites will be able to fully control who can request resources from outside the site and what remote locations should be reachable by content from within the site.

As seen in every aspect of Computer Security, the protection of a system is best achieved through a variety of overlapping controls. Site Security Policy aims to be one part of a larger defense-in-depth application security strategy, or as our colleague Gerv likes to say, "belt-and-braces". Web administrators, while maintaining their normal security auditing and remediation process, will embrace the opportunity to mitigate broad classes of web app vulnerabilities, for those users with compliant browsers, by defining a few simple rules.

Overview | Details | Download | Demo | Discussion