Re: Including the Javascript stack trace in the ContentSecurityPolicy report

2013/8/2 Henry Wong <>

> Hi,
> Thanks for the feedback. I have to admit that my experience is largely
> skewed towards the technologies and projects I use at Google, so it's great
> to hear other people's perspectives. I agree that a stack trace is often
> useless, but it's also often extremely valuable; with our error handlers
> (eg: window.onerror) we typically skew heavily in the direction of over
> reporting rather than under reporting. Is there a particular reason not to
> include the stack trace other than that it might not always be relevant?
If the downsides of over-reporting (bigger network requests, admittedly not
that much for that use case) are manageable, I don't think there is.

> Some further comments below:
> On Fri, Aug 2, 2013 at 2:33 PM, David Bruant <> wrote:
>> Hi,
>> I'd like to distinguish 2 cases: production and development.
>> In development, I believe that changing the platform would be a mistake
>> and that external tools like Casper.js [1] should be preferred (assuming
>> they report CSP violations [2])
>> Production is a different story as you can't embed tooling in your users
>> browsers. Since I consider developmeent dealt with with tooling, let's only
>> talk about production.
>> 2013/8/2 Henry Wong <>
>>> I'd like to propose that CSP reports include the Javascript stack trace
>>> that resulted in loading the forbidden resource (similar to window.onerror).
>>> In many large web applications (eg: Google+) it's almost impossible to
>>> figure out why a report was sent.
>> I imagine that in many large web applications, the JS is minified or even
>> optimized with things like inlining (through e.g. the Google Closure
>> Compiler) so I wonder how accurate and relevant the stack trace can be.
>> Also, with promises [3] and async programming rising up, I wonder how
>> relevant a stack trace can be. I know that in Node.js, a stack trace is
>> rarely a relevant piece of information to debug (we joke on a regular basis
>> with a friend on that topic).
>> The document uri is typically just "" which
>>> doesn't really give us enough context to know what the user was doing. For
>>> example, if an XSS spreads via users' chat status then a stack trace that
>>> pointed to the status message code would be much more useful than something
>>> that just said there was a report sent from somewhere on the page.
>> But I understand that you need some context for the violation. An
>> alternative idea to sending the stack trace could be adding a method like
>> "navigator.setCSPViolationContext(context)" (I don't know where CSP-related
>> methods are, but you get the idea).
>> If a violation is detected, the latest context value is sent along the
>> report (you can test that the right context is passed in developement mode
>> with [1][2] ;-) ).
> My main concern with this type of instrumentation is that it tends to be a
> bit brittle, especially in large development teams where not everyone is as
> knowledgable or careful as they could be. For example if an engineer
> forgets to set the context (or if the code throws an exception and breaks
> abnormally) then the context reported will be based on whatever previous
> code happened to have been run.
Agreed. The point I was trying to make is to have a higher-level mechanism
rather than stack traces, which depending on context (minified/inlined
code, etc.) may be hard or practically impossible to analyse. Not everyone
has Google's computational power and data analyst resources ;-)
I acknowledge that the particular solution I suggested is very error-prone
and isn't a good implementation, but I feel that the idea of a
developer-controlled higher-level mechanism should not be given up on just
yet (but I have to admit that I don't have a better idea yet).

> If you're wary of including the stack trace in the report by default then
> would it be possible to at least provide programmatic access to it?
You already do:
function s(){
        throw new Error();
        return e.stack
(you need to ignore the call to "s" as it's garbage, of course)

It's not standard, but works decently cross-browser. For standardization,
have a look on the ECMAScript side (it's not yet
on the standard track, but I feel it's only asking for people to push it)

> For example, the spec currently describes an experimental feature for
> SecurityPolicyViolationEvents<> -
> these are DOM events that get fired when a CSP report is created. An
> application could listen for these events and do its own custom reporting
> including adding a stack trace.
I wasn't aware of the event. That sounds like a good idea indeed!

> Unfortunately, the current implementation of the event in Chrome does not
> provide access to the stack trace as far as I can tell. Having the stack
> trace be included in the event would be great
I feel that it's an implementation limitation. Now that the stack trace is
available in window.onerror, I don't see why it wouldn't for this event.
In any case, the stack trace feels like only a small fraction of the
potential of the event. With the event, you can begin provide much *much*
more information about the context of the violation. You can send a portion
of a DOM tree for instance, why not the entire innerHTML if you want.

> alternatively being able to look at arguments.callee (or the equivalent in
> other browsers) would also be useful.
arguments.callee is standard, but throws in ES5 strict mode, I wouldn't
recommand using it.


Received on Friday, 2 August 2013 14:04:24 UTC