Hacker News Reader

Comment by ramimac | Hacker News Reader

We really aren't; even discounting people who home-roll it, many companies just don't use existing security features of languages well. An example I've seen in action is Rails' html_safe, which I've seen multiple developers use to make user supplied content "safe," when really it is meant to demarcate data that you have ensured is safe to include

View on HN

Not to mention the staggering number of tiny applications that were cobbled together in the Dark Ages and never updated.

Any thoughts on how can Ruby's html_safe be fixed to avoid that misuse of it?

I'm in no way an expert, so I don't know how qualified I am to comment. I'd say the issue isn't html_safe's functionality, but rather a common misunderstanding and misuse. In my experience this is steeped in the name "html_safe" itself, which leads developers to make incorrect assumptions. Really the problem is bad or uninformed developers, and you can only do so much to mitigate that.

I'd like to see the type system used to improve this stuff, by using more specialized types for different kinds of data. I don't think it's ultimately sensible that items as diverse as filesystem paths, SQL statements, HTML code, and raw user input are all represented as "strings." Imagine if instead you had a Path type, an SQLStatement type, an HTML type, and a UserInput type, and combining two items of mismatched types without the appropriate conversion/encoding was a hard error.

Here there isn't a type system, but his example of bad developers are going out of their way to defeat defaults by casting the HTML as "safe", so I don't know what hope there is for an automated solution.

Reply on news.ycombinator.com