

Javascript security - tonyskn
http://blog.jgc.org/2009/09/javascript-must-die.html

======
joubert
I think it would be better to not conflate language and runtime issues. For
example, one can improve language misfeatures such as semicolon insertion,
lack of built-in name pacing, etc. Even when you improved this, you would
still want to improve the (browser + DOM) architecture/runtime, but in many
cases these are orthogonal concerns.

------
DjDarkman
The global scope thing is not entierly true, you can use closures to minimize
the global scope usage.

The problem is not that bad: \- on the server side, always sanitize user input
\- only put script tags from places you trust

------
jgrahamc
Since this old presentation of mine has resurfaced (first on Reddit and now
here), here's the comment I made on Reddit:

    
    
      A good companion to this presentation is Douglas 
      Crockford's presentation on JavaScript security: 
      http://javascript.crockford.com/security.ppt (Warning: 
      PowerPoint).
    
      He makes similar points about the security of JavaScript 
      and comes up with a different solution. He proposes doing   
      away with most of JavaScript and allowing only a 
      safe-subset of the language to be used."
    

As a follow-up I had proposed signing of <SCRIPT> tags:
[http://blog.jgc.org/2009/09/solving-xss-problem-by-
signing-t...](http://blog.jgc.org/2009/09/solving-xss-problem-by-signing-
tags.html)

~~~
va_coder
Do you work on projects as a programmer where the project has rich ui
requirements and tight deadlines? I ask this because your advice not to use
Javascript is, to me, completely unrealistic.

~~~
jgrahamc
Yes, I manage a team of guys doing just that. And there's no avoiding
JavaScript today.

This was a presentation at a security conference.

~~~
va_coder
understood

I like how you mentioned frameworks like RoR that have XSRF prevention built
in. Not enough security talks mention things like that.

