StackOverflow flashback... Not sure who wrote this comment, and it's a little strongly worded, but man, they're on the money. ;^)

  • @samhocevar I can't believe you Little Bobby Tabled me. ;) If you're running text processed by client-side JavaScript on your database server without any safety checks, heaven help us all. ;^) Look, there shouldn't be anything any user can send from a client (eg, Postman) that gets past your server's security. And you should assume anything dangerous that could be sent from a client will be. That is, if you require 100% safety from client-side JavaScript code which is always user editable, and you think this function could open a security risk, you're playing in the wrong game. – ruffin Feb 19 '18 at 18:57  

I hope that makes sense. Sure, it's not bad to include some safety checks client-side, but they really are just niceties. Maybe you check a few things for your user's user input without a round trip to the server, but only after you've already put those same rules into your server's code.

(This, btw, is why Node is so intriguing. Write once with both sides in mind and you get client-side niceties for "free". Otherwise, if you push me to shoving, I'd say an mvp should only have input validation on the server [in ways that make it easy to return error packages to the client to display]. (And thus the * in the title... you can have it on the client, but it's not worth anything from the point of view of security.))

Honestly, this dev taking me to task by saying people can get formatUnicorn (read: client-side JavaScript code) to inject strings into (again) client-side variables... I mean, I can't even. WHY NOT JUST INPUT THE WACKY STRING TO BEGIN WITH? And to think that anything in JavaScript protects your server... Ugh. So many bad programmers loose these days. I'd like to think they're junior, but imagine that's a senior dev that forces juniors to protect against string injection in client code, maybe client code only. /shiver

Labels: , , , ,