text_area_tag not escaping content by default

I stumbled on the fact that text_area_tag does not HTML escape its
content by default. For example:

  text_area_tag "body", "</textarea><script>alert('xss');<script>"

If you try that, you'll see that the content is inserted literally.
Considering the fact that the tag helpers all encode their attribute
values by default, does this surprise anyone else?

I found a ticket on this issue from a couple years ago from Chris Mear
but it looks like it was dropped:

It seems like there were two main arguments against encoding:

1. backwards compatibility
2. some people depend on this behavior to allow HTML in their text
area boxes

#2 I don't really understand. You can allow HTML...just escape it.
It's equivalent to allowing HTML in a text field tag, no? You have to
either know the value is sanitized or escape it.

#1 I can understand, but that's not a show-stopper, right? There have
been numerous non-backwards-compatible changes adopted by introducing
them slowing, providing config options, etc.

I'm guessing there's quite a few people using text_area_tag and
assuming the content is being safely escaped by default. And every one
of them is an XSS problem.

It's an issue with anything that uses content_tag, of course. Try
this, for example:

  label_tag 'foo', "</lable><script>alert('xss2')</script>"

At the very least, are we amendable to adding a note in the
FormTagHelper docs about the escaping rules?

I've posted a new ticket on Lighthouse with an up-to-date patch:


I also noticed that the text_area method in FormHelper actually does
escape its contents now, so text_area_tag probably should do the same
for consistency's sake if nothing else.