- From: Alex Russell <slightlyoff@google.com>
- Date: Sun, 4 Nov 2012 20:58:33 +0000
- To: public-web-security@w3.org
- Cc: Webapps WG <public-webapps@w3.org>, Adam Barth <abarth@google.com>, Mike West <mkwst@google.com>, bhill@paypal-inc.com
- Message-ID: <CANr5HFWhKRxtjr_5Ws=U0pNLvP83PK+ear4RkZ2bFBLAmqORFA@mail.gmail.com>
Hi all,
Looking at Section 3.4 of the CSP 1.1 draft [1], I'm noticing that the IDL
specified feels very, very strange to use from the JS perspective.
For instance, the name "document.SecurityPolicy" would indicate to a mere
JS hacker like me that the SecurityPolicy is a class from which instances
will be created. Instead, it's an instance of the SecurityPolicy interface.
A more idiomatic name might be "document.policy", "document.csp", or
"document.securityPolicy" as leading-caps tend to be reserved for classes,
not instances.
Similarly, it's not possible (AFAICT) to new-up an instance of
SecurityPolicy and no API provided for parsing a policy to understand how
it would react.
Lastly, there's no serialization method provided. A toString()
implementation might work well. Here's some IDL and sample code that shows
how it might be repaired:
[NamedConstructor=SecurityPolicy,
NamedConstructor=SecurityPolicy(DOMString policy),
NamedConstructor=SecurityPolicy(DOMString policy, DOMString origin)]
interface SecurityPolicy {
readonly attribute DOMString[] reportURIs;
bool allowsEval();
bool allowsInlineScript();
bool allowsInlineStyle();
bool allowsConnectionTo(DOMString url);
bool allowsFontFrom(DOMString url);
bool allowsFormAction(DOMString url);
bool allowsFrameFrom(DOMString url);
bool allowsImageFrom(DOMString url);
bool allowsMediaFrom(DOMString url);
bool allowsObjectFrom(DOMString url);
bool allowsPluginType(DOMString type);
bool allowsScriptFrom(DOMString url);
bool allowsStyleFrom(DOMString url);
bool isActive();
DOMString toString();
};
// Examples from the draft:
var isCSPSupported = !!document.securityPolicy;
// or:
var isCSPSupported = (typeof SecurityPolicy != "undefined");
var isCSPActive = document.securityPolicy.isActive();
// Parse an "ssl-only" policy as though it were applied to example.com and
then test it:
var policy = new SecurityPolicy(
"default-src https:; script-src https: 'unsafe-inline'; style-src
https: 'unsafe-inline'",
"https://example.com");
// Can I load a font over HTTP?
policy.allowsFontFrom("http://example.com/"); // false
One open issue: I'm not sure If allowsEval, allowsInlineScript, and
allowsInlineStyle should just be boolean getters or if they should stay
methods. Also, it's unclear if the current document's policy should simply
be a locked-down instance of a SecurityPolicy class that has accessors for
each of the policy items (script-src, object-src, style-src, img-src,
media-src, frame-src, font-src, connect-src). I'm inclined to say "yes".
Thoughts?
[1]:
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#script-interfaces--experimental
Received on Sunday, 4 November 2012 20:59:32 UTC