Hacker News Reader

Comment by skyzyx | Hacker News Reader

This is bad advice. Definitely sanitize on input, then escape on output. You should never be knowingly storing unsafe input.

View on HN

"Unsafe input" is not a thing.

Actually, rather than sanitize input, I would recommend whitelist and reject in most cases. ID should be an integer, but you get a string with spaces around an integer? - error out. There's html in your text input? Error out.

In the vast majority of cases you control the client (web form) - anything "surprising" will then be an error - or worse; malicious.

In the case of a json service, if the client doesn't submit valid json for your schema / api - error out.

TFA touches on this with validation - validation is ux improvement - help the user submit only valid data. At that point there should be no proper use-case for invalid data to be submitted - hence reject, not sanitize and insert.

> There's html in your text input? - error out

How do you detect HTML? Less-than/greater-than signs? Users are now banned from entering Less-than/greater-than signs?

I once registered for a forum to ask a question, but they had it configured so new users couldn't submit URLs, probably to deal with spam. Their solution was to reject posts that contained what looked like URLs which means any time you don't put a space after a period, it's probably a URL. Like "That is fine.Pizza is good." -> http://fine.pizza detected, post rejected

But it gets worse. I had a code block in my post and it was also detecting URLs in my code.

`console.log` -> URL detected!

Good point. I guess I'm in agreement with tfa here - if special entities are ok, escape output. I don't think I want to allow a greater than sign in a "first name" field, but it might be perfectly valid in a text field. And if that field is text, not hypertext, escaping output seems sane. Maybe only where html is expected - say in the html part of an email, while the text part just uses a proper encoding.

Reply on news.ycombinator.com