As a blanket approach to dealing with XSS attacks, rather than having to remember to escape user-generated code, is there a way to instruct the browser not to execute any script or script-function which isn't signed with a particular public key (embedded in the top of every page, but not necessarily authenticated. This is only meant for dealing with XSS, not man-in-the-middle)? Then you could just sign all the "real" scripts


1 Answer 1


This would be a real hit to performance. Imagine you have a ton of embedded functions within your HTML page. Each would need to be signed seperately. Furthermore your server side code needs to be able to access your keystore to sign the code as often pages are generated dynamically. This would mean a substantial overhead to be dealt with.

Also note that JavaScript executing user input, which contains JavaScript will be hard to handle.

For instance let's say you have XSS on a user parameter which is embedded back into the page by a JavaScript function, your server will actually sign it before sending as it will not know that that part of the code isn't legitimate... and then we are back at the old problem of input/output validation.

Anyway most of this can be fixed with CSP anyway.

  • Yes, I see it's a performance hit for browsers, but not for the server. You sign the code ahead of time (as a "compilation" step), not dynamically. If you sign dynamically generated code, then that defeats the whole purpose (since dynamically generated code can contain user input).
    – dspyz
    Commented Mar 9, 2014 at 20:13
  • How many sites do you know that are worth performing XSS attacks on that aren't dynamically generated? Commented Mar 9, 2014 at 20:13
  • Well, the page could still have dynamically generated components, but those components would be unsigned. The unsigned parts are allowed to contain data, but not instructions/code/scripts of any kind. The point is, if the programmer forgets to do something or does it wrong, it will cause the script to simply fail to run (rather than run untrusted code).
    – dspyz
    Commented Mar 9, 2014 at 20:18
  • Once you've got the data separated it's pretty easy to go the whole hog and use CSP to enforce no in-page script at all. It's the separation step (avoiding inline event handlers, eval et al) that is the difficult bit.
    – bobince
    Commented Mar 10, 2014 at 17:32
  • Also if a signature is valid across the whole site, which presumably it would have to be if it's not dynamic, then an attacker could take a signed script block and inject it into a different victim page where it might have a negative effect. It just means the attacker has to inject larger building blocks than single lines of code. You could make the building blocks large and with well-defined interfaces, enough to be safe in any page, but then again, you've just done the separation job there and you could put them in external script files with CSP.
    – bobince
    Commented Mar 10, 2014 at 17:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .