5 important security measures every web developer should know and use

BIR62RGGjGxN5nrbnzwu_3Security for web apps is not “an option”.

When you are developing an app you need to take security into account from the very first lines of code. One of the most important things I like to keep top of mind is that you don’t know who your users will be.

Never trust a user.

They can be less web savvy than you, bringing so much clunkiness to your app that it breaks. That’s not their fault, it’s not your job to tell them to change their behaviour.
I run into these “Aha, so that’s what you do with my app?!” moments all the time. And I have to bite my tongue and take notes instead of explaining what they should be doing. These encounters remind me that my app not only works the way I planned it. It also ‘works’ in every other way a user can bend it.

Not all users are less savvy. They can be more savvy as well. They might even be malicious. Your app will eventually run into such a user. Even if your app is only used by a small number of people, the probability of a malicious user poking at your app sooner or later is very close to 100%. I know: it’s a hassle to keep thinking about security when you’re already working so hard to make your app behave exactly like you want to. So I made a short checklist of five things you should at least do to lower the chance of someone hacking into your app.
Note! This is just to get you started and by no means a definitive list. Every app has it’s own security challenges and you should investigate what measures you need to take for your specific app.

  1. **Never store a password in plain text. For one thing; users tend to use the same password for different accounts. If someone gets into your database, they have a big list of email addresses combined with passwords. Then it’s very simple to set up an automated process to run all these combinations through other services. If you’re not sure how to go about securing passwords, check this lifehacker page on how to securely store a password
  2. Force a secure connection. Even a cheap SSL certificate makes it a lot harder for a hacker to mess with your app. Get a certificate and install it on your webserver. Working with shared hosting? Contact the hosting company, they know how to do it. And after you or your host installed it, make sure that a visit to the non-SSL version of your website is always redirected to the SSL protected site.
  3. If you use sessions (and you probably do when you’re making a web app) make sure you use server side sessions. If you’re not sure, check the cookies for your apps domain. Is there any identifiable information in there? If so, change it! Any identifiable info helps a hacker getting into your system.
  4. When a user wants to change important personal information, ask for their password again right there. It doesn’t matter that you think it’s impossible for a hacker to get into someone elses account. a. Nothing is impossible and b. If changing that info is important, the user will definitely understand you ask for that password again.
  5. Never keep sensitive (user-) information on the front-end. Sometimes it’s very convenient to keep user data in local storage on the browser. Yes, I agree, it’s really easy to just have it at hand in your JavaScript. Don’t be tempted to do so. Again: The less you reveal about the underlying structure of your app, the better
  6. Bonus tip! Next to your app, you should also secure the computer(s) you use for development. And please don’t use FTP to upload or update your website! Use SFTP or FTP-S to make sure you’re not sending an unprotected password over the internet.

Please note: I am by no means a security expert! As I said before: these tips are just the ones I think any web developer should always apply. You should really make an effort to find out what security measures will stop hackers from getting into your app.

** I thought everyone knew by now but just weeks ago I ran into a guy who’s company offered a user log-in service(!!!) which stores plain text passwords. When asked about it, he told me it was so much more convenient for the end-users to receive their old password. And to add insult to injury he told us about another benefit: Some users called when they forgot their password and this way they could just tell them. I mimicked my deepest frown and told him we would not be using their service.