W3C home > Mailing lists > Public > public-web-security@w3.org > November 2012

CSP 1.1 DOM design

From: Alex Russell <slightlyoff@google.com>
Date: Sun, 4 Nov 2012 20:58:33 +0000
Message-ID: <CANr5HFWhKRxtjr_5Ws=U0pNLvP83PK+ear4RkZ2bFBLAmqORFA@mail.gmail.com>
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
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:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 4 November 2012 20:59:35 GMT