WebAppSec Content Security Policy
Home Page: https://w3c.github.io/webappsec-csp/
License: Other
CSP 3 is being specified in index.bs (published at https://www.w3.org/TR/CSP3/)
CSP 2 is published as a CR at https://www.w3.org/TR/CSP2/.
CSP 1 is published as a Note at https://www.w3.org/TR/2012/CR-CSP-20121115/
From @Nadoedalo on September 2, 2015 11:52
Seems that there is no way to set nonce attribute for a Web Worker in order to allow sandbox to do whatever it wants. Maybe there must be a way to set nonce-attribute in header or/and in script string/attribute?
I'm trying to run every unsafe-code in web worker's sandbox but only Chrome understands separate policy for the worker. And because of that I need to run 'unsafe-eval' policy just because I'm using template engine, and that can cause issues and not really offering me a protection.
Here are some links :
Firefox bug tracker
Stackoverflow question
Copied from original issue: w3c/webappsec#464
Expression matching algorithm tells us that expression without port-part should match a url with default for scheme port only:
If expression does not contain a port-part, and url’s port is not the default port for url’s scheme, return "Does Not Match".
Consider making scheme-source expression matching stricter by matching only default ports .
E.g.
script-src https:;
should match https://example.com but should not match https://example.com:8443
Also, default port is defined only for special schemes, meaning we have undefined behavior if scheme is not a special scheme.
CSP3 should clearly specify what considerations a document adding a new directive to the CSP header must address. A specific example is how to process multiple policies for a directive that doesn't have a clear algorithm for intersecting policies in a least privileged manner. (e.g. the previously proposed referrer policy directives or newly proposed cookie directives)
In case that we have an iframe inside an iframe, will the policy defined by the main browsing context still be enforced on the internal nested browsing context?
I couldn't find a reference to that case in the spec (might've missed it) so wanted to make sure.
From @ptoomey3 on September 23, 2015 0:12
I just wanted to open an issue to get your thoughts on form-action with respect to redirects. We have been working on deploying form-action and have run into a few scenarios that all boil down to:
POST to selfOne big use case of this is OAuth, where we have users submit a form to authorize access to their account. After the POST we redirect the user back to the OAuth application to complete the OAuth dance.
However, for these kinds of scenarios to work with form-action we would either have to:
form-action.meta refresh to redirect the user after authorizing (since this doesn't count as a form submit)I can see why one might want to limit method preserving redirection with a 307, but I couldn't think of much risk with allowing 302 style redirects. I guess there is some value in avoiding the redirection, though it feels somewhat orthogonal to the immediate risk associated with accidentally submitting form contents to an untrusted site. Anyway, I was just curious what your thoughts were on the topic.
/cc @mastahyeti @gregose @oreoshake
Copied from original issue: w3c/webappsec#482
Write text to that effect.
From @shekyan on October 2, 2015 23:31
Section 3.1 should be explicit how user-agent should behave in the context of malformed content-security-policy header.
For example, unknown directive, non-ASCII characters, multiple 'none' keywords in source-expression do not match the 'policy-token' grammar.
We suggest treating these headers as either default-src 'none' or default-src 'self'
Copied from original issue: w3c/webappsec#495
block-all-mixed-content doesn't actually appear in any CSP spec. It's only referenced in Mixed Content Section 4. "Strict Mixed Content Checking".
It seems like block-all-mixed-content would be the perfect directive to use with report-only, to slurp up information about offending contents, but it isn't currently supported.
Maybe using the word 'block' in report only is not accurate though. A different name like report-all-mixed-content might be best, where it is only valid when using CSP-RO, and must accompany a report-uri.
I imagine a header like this:
Content-Security-Policy-Report-Only: report-all-mixed-content; report-uri /report
upgrade-insecure-requests also doesn't work in report-only.
From @mastahyeti on August 6, 2015 5:19
The form-action directive is useful for limiting the domains to which forms can submit and could be used to limit the submission endpoints as well, though this is more difficult to implement. An interesting attack from @lcamtuf's Postcards from the post-XSS world article is the injection of a <form> above an existing <form>. Because form tags cannot be nested, the injected tag will take precedence over the legitimate one, inheriting any input tags, including any CSRF token, if present.
The form-action directive can prevent the injected form from exfiltrating the CSRF token by submitting the form to a malicious origin. It is more difficult though to prevent the injected form from submitting to an unintended same-origin endpoint. The effect of such an attack would be comparable to CSRF.
We've been playing with a few ways to protect against this attack. One approach is per-form CSRF tokens: embedded in each form's CSRF token is a signature of the intended method and action of the form. The signature is then verified by the server when the form is submitted. Another approach is to include the same form-nonce attribute in each form tag as well as in a meta tag. JavaScript then observes each form tag in the DOM and ensures that its nonce matches that of the meta tag, and otherwise deletes the form.
Both of these solutions are nasty to implement. Adding a form-nonce directive to CSP would make protecting against this attack easier for the implementer. This directive would function similarly to the JavaScript that I described. A nonce value would be provided in the CSP header and the user agent would disallow the submission of any form that didn't include the correct form-nonce attribute.
I'm curious for any thoughts on this idea, or on other protections against this attack.
/cc @mikewest @josh @oreoshake @gregose @ptoomey3
Copied from original issue: w3c/webappsec#448
Similar to what applies to schemeless resources where CSP allows https: loads, the spec should be changed to also allow https: loads to succeed if the CSP src is defined as http:
In easier words, taken a CSP:
img-src http:
the CSP should allow loading https: images.
That makes it harder for an attacker to exfiltrate (hoping I got my terminology right). Just to be clear, I realize the complexity might not be worth it, hence "consider".
From @mikewest on August 22, 2015 0:1
After a quick chat with @briansmith, I think I'm convinced that it would be worth giving subresource fetches the capability of canceling themselves based on the resources that requested them. That is, frame-ancestors (or embedder-src, or however we'd like to spell it) would work on <img> in the same way it works on <iframe>. This could shut down a class of information leakage attacks (e.g. Facebook might want to say that an image on their CDN can only be loaded in the context of facebook.com, but not in awesome-facebook-images.info), could make it moderately more difficult to detect whether a user is logged in (as logged-in-logo.png won't load on evil.com for anyone, logged-in or not), and could help defend against hotlinking.
Worth considering.
Copied from original issue: w3c/webappsec#458
From @klings on September 28, 2015 19:25
Declaring a CSP with connect-src ‘self’ will not allow websockets back to the same host/port, since they're not same origin. This might come as a surprise to developers that haven't studied the CSP specification in detail and have a firm grasp of the same origin security model.
One option could be to add a note to the spec to clarify that this is the intended behaviour. Another option could be to make an exception for connect-src 'self', and allow ws(s): requests to same host/port.
I'm not sure what the security implications could be of the latter, but it might be worth some consideration.
Copied from original issue: w3c/webappsec#489
From @ScottHelme on October 6, 2015 13:19
When receiving a report from the UA there is no defined method to identify whether it was the result of an enforced policy or a report only policy.
Is it possible to add a new key into the report JSON such as report-only:true when the UA received the policy in report only mode?
I've currently tackled this issue on the test site for https://report-uri.io by allowing the user to set a GET parameter in their policy reporting address which signals a report only policy. Whilst this works, it's not an ideal solution and depends upon the user to both set the value in the report only policy and then unset it when the policy is enforced. This has presented the opportunity for human error to cause inaccuracies in the categorisation of incoming reports.
GET parameters can be used as a standard method of transmitting additional information along with the report, yes, but it seems that whether or not the policy was enforced should be something that the user isn't expected to communicate.
Copied from original issue: w3c/webappsec#499
It may be useful to apply embedded enforcement to other contexts like <object>, <embed>, may be even svg?
I know for sure that one big company removed CSP from the web page that hosts swf files that are communicating to wherever. Those are third-party flash games, that are "randomly" picked on every page load. Sure they better load every swf in an iframe, but it'd be nice to have a CSP context directly on objects like that.
From @michaelficarra on October 6, 2015 23:38
At times, it is necessary to obtain a reference to the global object. In different environments, this object has non-standard, writable self-references: global in node, window in certain browser contexts, self in other browser contexts, etc. It is not a good practice to rely upon these references. For this reason, a particular pattern using the Function constructor is the only reliable method (of which I'm aware) for obtaining a reference to the global object in any context (strict/sloppy mode, module/script).
var honestToGodGlobalObject = Function("return this")();Because this is a use of the Function constructor, CSP does not allow this pattern without adding 'unsafe-eval' to my policy. How can we make an exception to allow this pattern or something equivalent?
Copied from original issue: w3c/webappsec#501
From @mikewest on September 17, 2015 9:39
It would be nice if, like <iframe sandbox>, we had the ability to constrain the things that a subframe can do. We can't do that by default, as CSP is way too granular to safely apply on behalf of a potentially malicious embedder. It might be workable if the embedee opts-in, however (via CORS or some new mechanism). This could, for instance, be a contractually-enforced portion of an advertiser's deal.
Something to consider for CSP3.
Copied from original issue: w3c/webappsec#474
While 'unsafe-inline', 'unsafe-eval', nonce-source, hash-source are valid source-expression values, only default-src, script-src and style-src define parsing for above keywords.
It would make sense to define something like executable-source-expression with appropriate grammar and use it for default-src, script-src and style-src, while make other source-list directives use source-expression.
Consider expanding base-64-value grammar to allow '_' and '-' -based encodings, sinse some browsers are ok with it anyway.
As suggested here, I'm opening an issue to describe a problem we've run into that prevents us from using sandbox on iframes.
In short, we run ads, and ads create iframes programatically. We don't know ahead of time where those iframes will be hosted. It'd be great to have a way of specifying a policy to apply to all cross-origin iframes.
I wrote up the problem more fully here: http://williambert.online/2015/10/How-HTML5-sandboxes-could-be-so-much-more-useful/
I confess to not reading the draft spec in its entirety, but I did find something that looks related to this in the Source Lists definition. The definition of host-part includes *. Would this allow me to write a CSP that applies sandboxing restrictions (including any allow flags that I choose to use) to any iframes created on my page from any and all origins?
A URL may legally include a trailing semicolon, even though that's unusual. In a CSP, the last token is followed by a semicolon. Therefore, for clarity of authoring, editing, and parsing, an author should space-separate a single or last URL and the semicolon that closes a directive's value and the specification should support that.
@hillbrad asked:
Need anything be said or done about ordering of headers? e.g. if Set-Cookie appears before Content-
Security-Policy? Or if the policy is in a meta tag? Do user agents uniformly process all headers before
getting to storage according to section 5.3 of RFC 6265?
I'm pretty sure all UAs grab all the headers before processing any of them, but I doubt any (including Chrome) process CSP before Set-Cookies. That said, we've gotten CSP wedged into the right place in Fetch's HTTP-network fetch algorithm (https://fetch.spec.whatwg.org/#http-network-fetch), so at least from the textual side we're covered.
We should add a note to the doc that spells that out in more detail.
In Section 2.1 it says "Each policy has an associated disposition, which is one of null, "enforce", or "report". The value is null unless otherwise specified."
A quick glance doesn't turn up any explanation of what a "null" disposition implies, except in the parser. Perhaps a sentence here would make things clearer for the reader?
From @kravietz on September 8, 2015 15:54
Reading through section 7.15 of the latest CSP2 editor's draft it seems like you can't whitelist an inline event handler with its SHA256 hash. Is this intended exclusion?
Just to provide a bit of background, the following script will only result in one pop-up, from the whitelisted alert in the <script> tag:
<!DOCUMENT html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="default-src none; script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='; img-src data:">
</head>
<body>
<img src="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'/>"
onload="alert('Hello, world.');">
<script>alert('Hello, world.');</script>
</body>
</html>
The inline handler alert will not be shown and Chrome will display the following error message:
Refused to execute inline event handler because it violates the following Content Security Policy
directive: "script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='".
Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to
enable inline execution.
Which on the other hand suggests that a hash could be used to whitelist it (but this may be just a Chrome catch-all message).
Copied from original issue: w3c/webappsec#468
Website always refer to third-party resources. When third-party resource was hacked, the server returns 401 HTTP header, then the browser will popup a window to let the user input user name and password, and the user may not know the username and password is needed by the third-party resource.
Currently only Chrome will block this 401 HTTP authentication popup. Other browsers don’t. This causes inconsistent user experiences and introduces security risks.
Can we have something in the CSP to block this ‚401‘ HTTP Authentication prompt?
Then the browser sees this policy, when the resource require 401 auth, this request can be blocked.
Also we should be able to block URLs with embedded user name and password.
Plugin types are not defined in the specification at all: https://w3c.github.io/webappsec-csp/document/#directive-plugin-types
The HTML spec has a section on plugins(https://html.spec.whatwg.org/multipage/infrastructure.html#plugins) but doesn't clear up how plugin names are resolved. It somewhat implies that plugins are registered against content types where text/plain and application/octet-stream are exempt from the algo.
Could we at least clarify for now that plugins are registered to a content type and provide some examples? I'm not sure if this was left vague so that it could be extended to other types of embedded plugins however providing examples might help clarify this at least?
Calling Function() as a function should also be blocked by a lack of 'unsafe-eval'.
User agents should either use the pre-redirect URL for that field, if it's available, or strip it as per http://www.w3.org/TR/CSP2/#strip-uri-for-reporting
From @mikewest on August 12, 2015 9:15
From https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0126.html:
https://code.google.com/p/chromium/issues/detail?id=511824 notes that
blob:URLs can be popped up into new windows, bypassing the inheritance
structure that CSP sets up for IFrames. Though this seems consistent with
the spec and with other browser's behavior, it's probably something we
ought to change in CSP3.Any objections to pushing CSP from an opener window to an openee in the
same cases where we'd push CSP from a parent frame to a child frame (e.g.
when the URL is a globally unique identifier)?
Copied from original issue: w3c/webappsec#451
In CSP3, source expression set of default-src is null if not explicitly present.
6.1.10.5. Get the effective source list for request and policy
If the effective directive for a request is not present in a policy, fetch directives will fall back to using the >value of default-src, if present. The effective source list
for a request (request) and policy (policy) is therefore determined by the following algorithm:1.Let effective be the result of executing §6.1.10.4 Get the effective directive for request on request.
2.If effective is null, return null.
3.If a directive whose name is effective is present in policy's directive set, return that directive’s value.
4.If a directive whose name is default-src is present in policy's directive set, return that directive’s value.
5.Return null.
Firstly, I believe step 2 needs to be removed because steps 3-5 would not be reached in the case that effective directive is not default-src.
Secondly, consider replacing 5 with something more restrictive. I would recommend one of 'none' or 'self' as a new default.
From @mikewest on August 17, 2015 13:47
If we end up breaking backwards compatibility, perhaps we could change the header syntax entirely as well. See https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0077.html for a brief discusion of that concept, and https://gist.github.com/jonathanKingston/5699b440f608960dc089 for a syntax proposal.
Copied from original issue: w3c/webappsec#457
From @mikewest on August 29, 2015 15:5
Nonce processing is fairly hand-wavingly defined in CSP2. We should formally integrate the definition with HTML's prepare a script and update a style block algorithms.
Copied from original issue: w3c/webappsec#463
@annevk suggested this in the Service Worker meeting when I complained about the algorithm in CSP. So let's think about that.
@rlbmoz proposed something like this in https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0070.html, and @annevk seems in favor. So, maybe it's worth doing.
Define what null is for every distinct context in the specification, or use "empty" instead.
For example,
If url's host is null, return "Does Not Match".
might be confusing.
From @michaelficarra on October 6, 2015 23:24
In section 7.15, "allowed script sources" is defined for source lists not containing 'unsafe-eval'. There appears to be an unnecessary qualifier, "When called as a constructor, ..." because, as ECMA-262 edition 6 states in section 19.2.1,
Thus the function call
Function(…)is equivalent to the object creation expressionnew Function(…)with the same arguments.
Copied from original issue: w3c/webappsec#500
From @michaelficarra on September 17, 2015 19:19
Step 8 explicitly allows 127.0.0.1 as the only IP address that may be matched. I think this should be expanded to include all loopback addresses, which includes the range 127.0.0.0/8.
Copied from original issue: w3c/webappsec#476
Something like dom-disable cookie domain; comes to mind as reasonable (as listing everything we enable would be prohibitive). Perhaps in a new "document feature" document, along with sandbox, base-uri, plugin-types, form-action, and permissions (a la w3c/webappsec#206)?
Maybe frame-ancestors too.
From @mikewest on September 22, 2015 17:13
Let the default sources be the result of parsing the default-src directive’s value as a source list if a default-src directive is explicitly specified, and otherwise the U+002A ASTERISK character (*).
This is a copy/paste error on my part. A missing default-src should have no effect; as written, it would block inline script and eval.
Copied from original issue: w3c/webappsec#481
Move http://www.w3.org/TR/CSP2/#frame-ancestors-and-frame-options from CSP 2 to CSP-DOCUMENT.
From @michaelficarra on October 6, 2015 12:57
See my comment in w3c/webappsec#495 (comment).
4.2.1 separates source expressions on U+0020 (space), U+0009 (tab), U+000A (line feed), U+000C (form feed), and U+000D (carriage return), and the source-list grammar separates source expression on WSP, which is only U+0020 (space) and U+0009 (tab).
I think we should just replace usage of RFC 5234 WSP (the latter usage above) with HTML5's space characters (the former usage above).
Copied from original issue: w3c/webappsec#498
When I read CSP2 spec, it is not clear which text encoding should be used to compute the hash value of inline script/style. Is it the original encoding of the HTML page? Is it UTF-8 or UTF-16LE/BE?
One example in the spec (" SHA-256 digest of alert('Hello, world.'); is qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=") implies the encoding is ASCII-compaitable, so I guess UTF-8 should be used?
In https://w3c.github.io/webappsec-csp/#match-url-to-source-expression, section
If expression does not have a scheme-part, then return "Does Not Match" unless one of the following conditions is met:
origin's scheme is url's scheme
origin's scheme is "http", and url's scheme one of "https", "ws", or "wss".
origin's scheme is "https", and url's scheme is "wss".
looks incorrect to me, as it implies that url would match solely based on the schemes of url and origin
I think it is missing explicit statement that the rest -parts should match. If that's what you meant, I can try to fix this.
Can you please clarify in the example section what is the threat model this feature is trying to fight. We even looked at the (minutes)[http://www.w3.org/2015/10/28-webappsec-minutes], but it still not clear what is this for.
From @michaelficarra on September 17, 2015 19:17
Schemes elsewhere in the CSP specification are treated case insensitively, but the wording here
... and url’s scheme is not one of
blob,data,filesystem, then return does match.
suggests a case-sensitive comparison. I believe this is an oversight.
Copied from original issue: w3c/webappsec#475
Speculative loading is particularly challenging if a Meta CSP is present on a page, hence we (Mozilla) propose that Meta CSP should be simply ignored (log a warning to the console) if it appears after a <script> tag within the portion of a document. Currently the spec states:
"Authors are strongly encouraged to place meta elements as early in the document as possible, because policies in meta elements are not applied to content which preceeds them."
In more detail, lets assume the following example:
head
script document.write("<!--") /script
meta csp-stuff-here
/head
body
I am still a comment. --> But I am not.
img src="the-meta-csp-better-not-apply-here"
/body
In the above example, the meta CSP policy would be applied to the preload, but not to the actual load. In a different scenario it's even worse. Let's assume:
head
script document.write("<meta csp...>"); /script
/head
body
img src="foo.jpg"
In the above example, no CSP would be applied to the preload but to the actual load it would. I don't have to discuss what security implications this has. (Hopefully no sane web page author would ever do that, but who knows ...)
In addition, CSPs are additive, which means CSPs delivered through the header are merged with any Meta CSPs present on the page. Now one can assume that you can have all sorts of combinations, a CSP delivered through the header plus three meta CSPs where the second is commented out by document.write, etc. One can assume that this gets really messy and in our opinion not worth the effort, the implied slowdown for no security gain whatsoever.
We are open for discussions though!
(Edited by @mozfreddyb: Added markdown syntax foo, because the web interface started swallowing stuff after the initial script tag)
From @shekyan on October 7, 2015 0:39
Section 7.15 mentions operator eval
If 'unsafe-eval' is not in allowed script sources:
Instead of evaluating their arguments, both operator
evaland functioneval[ECMA-262] MUST throw an EvalError exception.
Operator eval is is not defined neither by ECMA-262, nor by the CSP specification.
Copied from original issue: w3c/webappsec#503
From @lweichselbaum on September 8, 2015 9:12
It would be great, if SecurityPolicyViolationEvents could be used to track down the exact element in the DOM that caused a CSP violation.
When adopting CSP the problem is often tying a particular violation to a given element on the page so the developer can change their templates/code to avoid it. What we currently have is heuristics to e.g. walk the DOM to see if there are any elements with inline event handlers, but this is a bit hacky and not guaranteed to work. Having a reference to the exact element would let us report the xpath, or do nice things on the client-side like highlighting the element. So it might turn out to be one of those tiny things that end up making CSP adoption quite a bit easier.
Copied from original issue: w3c/webappsec#467
Could we consider decoupling <style> and style="..." usage in style-src 'unsafe-inline' CSP setup?
The rationale is that as far as I am aware style="..." has no modern security issues in CSP supporting browsers; where as given selector support <style> could be manipulated to check for data on the page and load images.
For example there are various teams wanting to implement CSS parsers to get around the style="..." support issue, where as <style> seems mostly easy to move to a secure setup. So for example Ember team is willing to take the property in and set it as JavaScript attributes after parsing to mitigate the warning.
There could also be room to discuss if granularity for SVG <style> tags could be separate too I guess?
@mozfreddyb mentioned that he would like to see scoped styles granularity also which probably makes sense too.
/cc @mikewest
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.