In one case two years ago (not a Rails app but it would have been) the QA team verifying the app we built had some sort of automated tool that checked for XSS vulnerabilities to the extreme and forced us to address each and every one of them, despite the fact that it was an internal-facing webapp. Major FPITA.
Having a config setting which addressed XSS all at once (if possible and performant, which I'm not claiming it is) would be interesting and potentially useful. I don't think Nathaniel should be slapped down for suggesting it, and I do believe he was slapped down a bit. A different approach might be to leave <%= alone and introduce a different ERB operator that is XSS safe, perhaps <%: ... my point is there are probably lots of different ways to attack this problem. Are there more important issues to address? Probably. Obie On 2/12/06, Francois Beausoleil <[EMAIL PROTECTED]> wrote: > Hi ! > > 2006/2/12, Tobias Luetke <[EMAIL PROTECTED]>: > > huh? that would break url_for, link_to, textilize, markdown and every > > single other helper which outputs html tags. I use the h helper in > > like 3 different places in shopify, thats definitely the exception. > > Am I reading this right ? 3 places ? I use it on every list screen I > have. I don't trust the admin interfaces anymore than I would trust a > public comments form. So, I even HTML escape product names and codes. > > Could you explain which places you do and don't use HTML escape ? > Maybe I'm too paranoid ? > > Thanks ! > -- > François Beausoleil > http://blog.teksol.info/ > > _______________________________________________ > Rails-core mailing list > [email protected] > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > > _______________________________________________ Rails-core mailing list [email protected] http://lists.rubyonrails.org/mailman/listinfo/rails-core
