W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2013

SecurityPolicyViolation DOM events.

From: Mike West <mkwst@google.com>
Date: Tue, 19 Mar 2013 11:22:19 +0100
Message-ID: <CAKXHy=f2k0razyzf139Vf9n2u+Ysasam_DDpWN97G4zJc8y5xw@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Cc: "dveditz@mozilla.com" <dveditz@mozilla.com>, Adam Barth <w3c@adambarth.com>, "Hill, Brad" <bhill@paypal-inc.com>
In https://dvcs.w3.org/hg/content-security-policy/rev/0c7cb63e2e48, I've
stubbed out an initial pass at a SecurityPolicyViolationEvent interface.
I'd appreciate some feedback on both the content and the language used to
describe it. I tried to steal context from other specs, but none really did
exactly what I wanted. Ah well.

In a nutshell, the intent is to fire 'securitypolicyviolation' events at
the protected resource's Document. Each event contains the same properties
as the current report object, which seems like a reasonable first step.
Once we go around a bit on the core, I'm thinking about three additions:

1. Policies should be able to opt-out of DOM-level reporting, as discussed
in
a November 2012 thread[1].

2. Violation events should possibly include a DOM reference (perhaps as a
'relatedTarget'?) to the node that triggered the error (see the same
thread[1] for context).

3. A running list of violation events should potentially be stored
('document.securityPolicyViolations'?) so that violations that occur before
a developer hooks up an event handler can still be dealt with in some
fashion.

[1]: http://lists.w3.org/Archives/Public/public-webappsec/2012Nov/0128.html

Feedback is much appreciated.

--
Mike West <mkwst@google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Received on Tuesday, 19 March 2013 10:23:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:00 UTC