idnits 2.17.1 draft-gondrom-websec-csp-header-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 235, but not defined == Unused Reference: 'CLICK-DEFENSE-BLOG' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'CSRF' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'Clickjacking' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'FRAME-OPTIONS' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC0822' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'W3C' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'W3C-CSP' is defined on line 333, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBSEC A. Barth 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track T. Gondrom 5 Expires: September 7, 2012 March 6, 2012 7 HTTP Header Content Security Policy 8 draft-gondrom-websec-csp-header-00 10 Abstract 12 To communicate the Content Security Policy (CSP) as defined by the 13 W3C, the web server needs to send a HTTP header to the browser 14 (client) to inform it about the content security policies that SHALL 15 be applied on the client. This draft outlines the header to 16 communicate the CSP with its fields. The definition of the semantic 17 of the directives will be done by the Web Application Security 18 Working Group at the W3C. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 7, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 56 3. Content Security Policy Header . . . . . . . . . . . . . . . . 3 57 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4.1. Content-Security-Policy . . . . . . . . . . . . . . . . . . 4 59 4.2. Content-Security-Policy-Report-Only . . . . . . . . . . . . 4 60 5. Augmented Backus-Naur Form (ABNF) . . . . . . . . . . . . . . . 5 61 6. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7. Source List . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8. Directives . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 11.1. Registration Template . . . . . . . . . . . . . . . . . . . 7 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 13.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 13.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 In 2011 the W3C started the working group "Web Application Security 77 Working Group" to work on a future Content Security Policy. A policy 78 language intended to enable web designers or server administrators to 79 declare web application content security policy. The goal of the 80 specification is to reduce attack surface by specifying overall rules 81 for what content may or may not do, thus preventing violation of 82 security assumptions by attackers who are able to partially 83 manipulate that content. 85 The goal of this drafts is only to document and specify the HTTP 86 header used to communicate the Content Security Policy as specified 87 by the W3C working group. 89 2. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 3. Content Security Policy Header 97 The Content Security Policy (CSP) HTTP response header indicates a 98 policy to be enforced by the browser on from which sources different 99 types of content will be allowed to load and possibly execute. Hosts 100 can declare this policy in the header of their HTTP responses to 101 prevent Cross Site Scripting, Cross-Site Request Forgery and 102 clickjacking attacks, by ensuring that content from untrusted sources 103 is not loaded/executed in web pages or frames. 105 4. Overview 107 The header field name is: 108 Content-Security-Policy 110 Please note, that previous experimental implementations prior to this 111 standard may use the header name X-Content-Security-Policy, which 112 does not indicate any conformance with this standard. 114 The server transmits its security policy for a particular resource 115 using a HTTP header with the label "Content-Security-Policy" followed 116 by a collection of directives, each of which controls a specific set 117 of privileges for a document rendered by a user-agent. More details 118 are provided in the directives section. 120 In general any directive consists of a directive name, which 121 specifies the privileges controlled by the directive, and its 122 directive value, which specifies the restrictions the policy imposes 123 on those privileges. 125 [TBD] do we need to mention the HTML meta tag here as well? 126 The CSP SHOULD be delivered from the server to the client via an HTTP 127 response header. Another less recommended alternative is an HTML 128 meta element. Servers should use the HTTP response header mechanism 129 whenever possible because, when using the meta element mechanism, 130 there is a period of time between when the user agent begins to 131 process the document and when the user agent encounters the meta 132 element when the document is not protected by the policy. 134 4.1. Content-Security-Policy 136 A server may supply one or more CSP policies in HTTP response header 137 fields named Content-Security-Policy along with the protected 138 content. Upon receiving an HTTP response containing more than one 139 Content-Security-Policy header field, the user agent MUST enforce the 140 most combination of all the policies contained in these header 141 fields. [TBD] should this be the most restrictive combination? 143 4.2. Content-Security-Policy-Report-Only 145 As an alternative, the server can also use the HTTP header "Content- 146 Security-Policy-Report-Only" header field to experiment with CSP by 147 only monitoring (instead of enforcing) the policy. This feature 148 allows server operators to develop their security policy in 149 iterations. They can deploy a report-only policy based on their best 150 estimate of how their site behaves. And if the site violates this 151 policy, instead of breaking the site, the user agent(s) will send 152 violation reports to a URI specified in the policy. Once a server 153 has confidence that the policy is appropriate, it can promote the 154 report-only policy to full "Content-Security-Policy" (blocking) mode. 155 As with "Content-Security-Policy", a server may supply one or 156 multiple of these policies in HTTP response header fields named 157 Content-Security-Policy-Report-Only along with the protected content. 158 Upon receiving an HTTP response containing more than one Content- 159 Security-Policy-Report-Only header field, the user agent MUST enforce 160 the most combination of all the policies contained in these header 161 fields. [TBD] should this be the most restrictive combination? 163 A server MUST NOT provide Content-Security-Policy header field(s) and 164 Content-Security-Policy-Report-Only header field(s) in the same HTTP 165 response. If a client received both header fields in a response, it 166 MUST discard all Content-Security-Policy-Report-Only header fields 167 and MUST enforce the Content-Security-Policy header field. A warning 168 SHOULD be send to the report URI as specified in the Content- 169 Security-Policy, if the report address is specified. 171 5. Augmented Backus-Naur Form (ABNF) 173 The RFC 5234 [RFC5234] ABNF of the CSP header is as follows: 175 6. ABNF 177 The ABNF is as follows: 179 csp-header = "Content-Security-Policy:" OWS policy OWS 181 policy = directive-list 182 directive-list = [ directive *( ";" [ directive ] ) ] 183 directive = *WSP [ directive-name [ WSP directive-value ] ] 184 directive-name = 1*( ALPHA / DIGIT / "-" ) 185 directive-value = *( WSP / ) 187 7. Source List 189 Many CSP directives may refer to sources from which content / 190 resources may be loaded. These sources are defined as a value 191 defined by a source list. Each source expression in the source list 192 represents a location from which content of the specified type can be 193 retrieved. The source expression 'self' represents the set of URIs 194 which are in the same origin (as defined by SAMEORIGIN [RFC6454]) as 195 the protected document and the source expression 'unsafe-inline' 196 represents content supplied inline in the document itself. 198 source-list = *WSP [ source-expression 199 *( 1*WSP source-expression ) *WSP ] 200 / *WSP "'none'" *WSP 201 source-expression = scheme-source / host-source / keyword-source 202 scheme-source = scheme ":" 203 host-source = ( [ scheme "://" ] host [ port ] ) 204 keyword-source = "'self'" / "'unsafe-inline'" / "'unsafe-eval'" 205 scheme = production from RFC 3986 206 host = "*" / [ "*." ] 1*host-char *( "." 1*host-char ) 207 host-char = ALPHA / DIGIT / "-" 208 port = ":" ( 1*DIGIT / "*" ) 210 8. Directives 212 The following CSP directives are defined: 214 default-src 215 If this directive is set, it it sets the default source for all 216 directives that are not explicitely specified. 218 script-src 220 object-src 222 style-src 224 img-src 226 media-src 228 frame-src 230 font-src 232 connect-src 234 sandbox 235 [TBD]??? 237 report-uri 238 Reports of violations of the CSP will be send to this URI 240 policy-uri 241 URI to load the CSP 243 9. Examples 245 Example Cases 247 10. Acknowledgements 249 This document was derived its input from specifications published by 250 W3C and developed by various browser vendors like Mozilla, Google, 251 Microsoftm Opera and Apple. 253 11. IANA Considerations 255 This memo a request to IANA to include the specified HTTP header in 256 registry as outlined in Registration Procedures for Message Header 257 Fields [RFC3864] 259 11.1. Registration Template 261 PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE: 263 Header field name: Content-Security-Policy 265 Applicable protocol: http [RFC2616] 267 Status: Standard 269 Author/Change controller: IETF 271 Specification document(s): draft-gondrom-websec-CSP-header 273 Related information: 275 Figure 1 277 12. Security Considerations 279 The introduction of the CSP http header improves the protection 280 against Cross Site Scripting, CSRF and Clickjacking, however it is 281 not self-sufficient on its own but MUST be used in conjunction with 282 other security measures like secure coding, the Same-Origin Policy, 283 Frame-Options, etc, 285 13. References 287 13.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 13.2. Informative References 294 [CLICK-DEFENSE-BLOG] 295 Microsoft, "Clickjacking Defense", 2009, . 299 [CSRF] OWASP (Open Web Application Security Project), "OWASP 300 Top-10: Cross-Site Request Forgery (CSRF)", 2010, 301 . 303 [Clickjacking] 304 OWASP (Open Web Application Security Project), 305 "Clickjacking", 2010, 306 . 308 [FRAME-OPTIONS] 309 IETF, "The Frame-Options", December 2010, . 312 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 313 text messages", STD 11, RFC 822, August 1982. 315 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 316 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 317 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 319 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 320 Procedures for Message Header Fields", BCP 90, RFC 3864, 321 September 2004. 323 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 324 Specifications: ABNF", STD 68, RFC 5234, January 2008. 326 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 327 December 2011. 329 [W3C] W3C, "W3C: DRAFT Web Application Security Working Group 330 Charter", 2012, 331 . 333 [W3C-CSP] W3C, "W3C: CSP", 2012, 334 . 336 Authors' Addresses 338 Adam Barth 339 Google, Inc. 341 Email: ietf@adambarth.com 342 URI: http://www.adambarth.com/ 343 Tobias Gondrom 344 Kruegerstr. 5A 345 Unterschleissheim, 346 Germany 348 Phone: +44 7521003005 349 Email: tobias.gondrom@gondrom.org