Python's Jinja templating language has the concept of "safe" and "unsafe" strings. By default all strings are unsafe (meaning they will be escaped wherever they are rendered) and you need to explicitly mark them as safe in order to be able to treat them as HTML.
React and Angular (and maybe Ember too?) similarly auto-escape any strings to be rendered and only provide very explicit ways to circumvent that (in React it's even called "dangerouslySetInnerHTML" and takes an object with a property called "__html" rather than a string[0]).
You can avoid XSS in dynamically typed languages. You just need to make it easier to do the safe thing than the difficult thing.
[0]: I really like React's approach to naming APIs you should think twice about using. For legacy reasons ReactDOM is still bundled as part of React and exposed with a property but the name of that property is "__SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED" (presumably to prevent React maintainers / Facebook employees from using it).
I wasn't implying dynamically typed languages were worse that statically typed languages. I was just discussing the approach I used to mitigate human error when building web UIs in hope it might inspire other people (or other people might offer additional feedback that inspire improvements in my own framework).
It is interesting to see that other frameworks are using similar ideas to my own though. Maybe not surprising; but at least reassuring to know that my own quirky API design isn't as leftfield as it felt when I was developing it.
> Python's Jinja templating language has the concept of "safe" and "unsafe" strings. By default all strings are unsafe (meaning they will be escaped wherever they are rendered) and you need to explicitly mark them as safe in order to be able to treat them as HTML.
That's good, but it's not ideal as it confuses HTML/unsafe. An unwary developer could output untrusted text "safely" and still open up an XSS vulnerability – because they could be outputting to JavaScript embedded within HTML. Yes, Jinja will encode it as HTML by default, rendering it "safe" in terms of the HTML parser, but that still doesn't make it actually safe.
Example:
alert("Hello, {{user.name}}!");
By default, Jinja will encode this as HTML, meaning that you can't trick the HTML parser into injecting your HTML. But it is still completely vulnerable to the exact same security vulnerability, except by tricking the JavaScript parser.
We should recognise what's actually the issue at play here. It's not really about whether data is safe or not. It's about correctly encoding data in a manner that's suitable for the context in which it is being output. Sometimes that's HTML, sometimes it's JavaScript, sometimes it's CSS, etc.
React and Angular (and maybe Ember too?) similarly auto-escape any strings to be rendered and only provide very explicit ways to circumvent that (in React it's even called "dangerouslySetInnerHTML" and takes an object with a property called "__html" rather than a string[0]).
You can avoid XSS in dynamically typed languages. You just need to make it easier to do the safe thing than the difficult thing.
[0]: I really like React's approach to naming APIs you should think twice about using. For legacy reasons ReactDOM is still bundled as part of React and exposed with a property but the name of that property is "__SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED" (presumably to prevent React maintainers / Facebook employees from using it).