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: , , , ,