Don't trust the user

- [Instructor] The most dangerous component of any digital interaction apart from you, the developer, and the app, and the device, and the provider is the user. The human being left to their own devices quite literally to navigate and use whatever you've built. The user, no, let's put a human face on the people we build things for. The person touching, or swiping, or clicking, or typing, or otherwise using the thing you've built is the most likely trigger for something going wrong with that thing. And in more cases than I think any of us would be comfortable to admit that something going wrong constitutes a security risk. Don't trust the user is a common statement when discussing software security. And it's an important principle, but without proper context, a statement like that can easily feel and be interpreted as a devaluing of the person using their developed thing. And infantilization, a suggestion that the user is too inexperienced or uneducated or quite literally dumb to understand that they're not using things properly. That's not what don't trust the user means at all. Don't trust the user means the person using the thing you build does not know what you know about their usage and how that usage can lead to unexpected, unwanted, or even dangerous or harmful outcomes and they shouldn't have to. The person using your creation should not be able to do anything that leads them to unexpected, unwanted, dangerous, or harmful outcomes because the onus is not on your user to protect themselves. It's on you. So when we say don't trust the user, we mean given the opportunity the person using anything you build is likely to do something wrong or unexpected until they know how to do it right. And it's our responsibility as developers to ensure when they do, they're intercepted and guided towards the action they wanted to perform. Let me give you a real world example of this. Years ago I was asked to help with a news website that had a weird problem. When you visited the front page and clicked on the title of an article, the front page would reload instead of taking you to the article page. This was extra weird because the content management system being used created the front page and the links automatically. The writers had no way of setting the links or so I thought. Inspecting the HTML of the page I discovered each title was wrapped in a link element that was then wrapped around another link element. The outer link pointed at the article while the inner link pointed back to the front page. If you do this in HTML, nesting links inside other links, the innermost link is the one that works thus the navigation back to the front page. What I couldn't figure out was why this inner link was there to begin with. So I went back to see what was going on on the back end. And there I found the reason. When articles were put into the CMS, the editor, the human, added a link bank to the homepage around the title in the title field. And for some reason the CMS wasn't sanitizing this field so the HTML element wasn't stripped out. The intent of the editor was for readers to be able to click on the article title in the article pages to return to the front page, which I had to explain is an unexpected UX pattern and not a good design. But the bigger issue here was that the CMS allowed for HTML in the title field at all which could lead to far worse things than this double linking. The lesson, don't trust the user to not put HTML elements where they don't belong, or more practically, assume people will do surprising things like put HTML elements where they don't belong. And it's your responsibility as a developer to either prevent them from doing this or cleaning up the form input so they avoid unexpected behavior. Don't trust a user to fix your software. Fix it yourself.