- 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