I’m all for encouraging people to take up web development if it’s a career that appeals to them, but I’m also wary that some ability to code in PHP and a basic understanding of how databases work does not a web developer make.
One of the most important skills a web developer can cultivate is a proper understanding of the security context in which they work. Sometimes that message is difficult to get across to novice web developers, who are itching to apply their hard-won skills to building tools and services of practical value. I’ve frequently come across web developers who are skilled coders, but who have a naïve view of security and impatience with the way building secure web applications can slow down the development process.
One of the best ways to reduce the number of data breaches and compromised servers is to educate web developers about the security mistakes they’re most likely to make and how to avoid them.
To that end, I’m going to look at five of the most common security errors new (and not so new) web developers make.
Leaving Databases Exposed To The Open Web
Towards the end of last year it was revealed that the data stored in thousands of MongoDB databases was accessible to anyone who knew the IP of the server on which they were hosted. The situation resulted from an unfortunate combination of poor default configuration on the part of MongoDB and lack of knowledge on the part of web developers, who didn’t change the default configurations.
Databases should never be directly accessible from the open web; they should only be accessible within a private network and the data stored in them should only be exposed via the web application they support.
Creating Their Own Encryption Implementation
Cryptography is one of the most difficult mathematical and computer science fields in the world. And yet, every now and then, a web developer will think that they’ve come up with a great new way to implement a particular algorithm or even invented a novel algorithm of their own.
This is hubris and, unless you are a brilliant cryptographer with a Phd in the relevant field (and probably even if you are), don’t be tempted.
“When I was in college in the early 70s, I devised what I believed was a brilliant encryption scheme,” wrote cryptography expert Phillip Zimmerman. Later, he found the scheme was “presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme.”
It’s also a complete waste of time, because every programming language used in web development has tried and tested libraries that will take care of this stuff for you.
Trusting User Input
If there’s a chink in the armor of a web application that allows a malicious user to run code in the database, in the application itself, on the server, or on another user’s browser, it will be found and exploited.
Smart web developers trust no one, and every bit of user input, no matter what the source, is checked and sanitized to render it inert.
This is easier said than done, and many experienced web developers have accidentally left the door open — that’s why SQL injection and cross-site scripting attacks are so common — but as a general mindset, it’s useful for novice developers to assume that any source of user input is a potential security risk.
Storing Passwords In Plain Text
Hash and salt passwords. Do not store plaintext passwords in databases. No excuses.
Putting Security Last
Most security vulnerabilities are not caused by malice or laziness, but by a desire to get a product built and shipped as soon as possible. When it’s a choice between poring through MongoDB’s documentation looking for potential security problems, and implementing a shiny feature that will make users happy, less experienced web developers choose the latter.
In the short term, that might make sense, but when your “we’ll do it properly later” kludge leads to a massive data leak, you’ll wish you’d taken the time to do it right the first time around.