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

Re: Including the Javascript stack trace in the ContentSecurityPolicy report

From: David Bruant <bruant.d@gmail.com>
Date: Fri, 2 Aug 2013 17:50:30 +0200
Message-ID: <CAHbscB3_i17EDv7HptA-2v0QWa1qaYXimTVVYSgSPpdYTmovaw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webappsec@w3.org
2013/8/2 Boris Zbarsky <bzbarsky@mit.edu>

> On 8/2/13 9:29 AM, Henry Wong wrote:
>
>> Is there a particular
>> reason not to include the stack trace other than that it might not
>> always be relevant?
>>
>
> It's a significant burden on implementations to do it, especially without
> killing performance.  Because loads are async, any operation that might
> start a load has to eagerly save the stack trace just in case the load will
> later fail a CSP check...
>
All the CSP rules have to be known by the runtime *before* any load, aren't
they? So I don't understand why asynchrony would be an issue. In essence,
an implementation can do (pseudo-JS code, lots of details omitted):

function load(url){
  if(url.violatesCurrentCSPRules()){ // sync because all rules are
available. Has to be done anyway by a CSP conforming impl.
    var stack = getStackTrace();
    // emit the event with the stack as one of its data
    // send the violation report
  }
  else{
    // sendHTTP request
  }
}

The extra cost only occurs if a violation is detected which is expected to
be a rare event.

David
Received on Friday, 2 August 2013 15:50:58 UTC

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