Security for full-stack web developers: Part 1

Being a full-stack developer is enormously rewarding and gives us a lot to think about from day to day. Each time we engage in a new project, we all have our own little routines and unique checklists in which we find our ideological backbones to power our project. Naturally, the biggest considerations are paradigm, language & framework. Then we have databases, data sources and data API’s. Then infrastructure and operations etc. Now, while these considerations are discussed and chosen, more commonly we are missing one of the most important considerations of all — Security.

In 2016–17, there were over 4.2billion Personal Data Records compromised and leaked. There were 94 reported incidents that exposed each; at least one million records — and 37 incidents exposing ten million or more records. Compared with 2015, this marks an increase of 63% and 105%, respectively.

This data comes from ‘Risk Based Security’s end of year 2016 report ’.

I realize reading an article introduction like the above is a little frightening, certainly it used to scare me! The sheer number of data breaches that happen on a daily basis is extremely concerning, and as a Developer, it’s one of our responsibilities to ensure that these data breaches don’t happen! I’d like to share my checklist, both paradigm/language agnostic & framework specific, to ensure you get the best possible start to securing your new projects.

Security is an ongoing, and ever-changing, practice that you must observe to ensure your project is never included in the companies that one hears about on the news after a huge data breach. Regardless of which programming paradigm, language or framework you wish to use, there are plenty of non-specific, terse security practices you should follow from the very start of the project. I will also dive a little deeper into specific best-practices later on in this article, and the next two articles in this series.

In my last Startup, we provided User Authentication as a Service so we were a major target for hackers. On one of our first evenings live, we watched someone attempt to send 5million malicious requests within 30 minutes. None of which had any affect other than exposing the hacker. This is because we made security a priority — which is something we all need to do in the modern world of Tech.

Let’s jump in and take a look at some important best practices:

Take a Tech Blueprint

Note — In my opinion, this is the most important checklist item.

Do you know the ins-and-outs of each library your Developers use? Probably not — it’s near impossible to keep track nowadays, but this is to great detriment. Are you also aware of which libraries and tools have been given write access to your production servers and databases — and how isolated they are?

The issue here is that using so much automation in modern development, we grant access to a huge amount of tools/libraries without really knowing exactly what they’re doing. We take it for granted that each of these libraries is entirely safe and without their own security vulnerabilities — or worse — performing malicious activities themselves.

We all want the most streamlined Dev cycle possible. We all use automation tools that trigger a whole bunch of processes, doing things that barely any of us are aware of. The propensity of some Devs to throw sudo commands at package managers if a command fails is also terrifying.

So how do we get around this? Take a Tech Blueprint! This needn’t be a complex process, it’s as simple as knowing which pieces of Software do what on your servers and how much authority you’ve granted them. Take a note of any new tools / packages before you grant them permissions, and do a little research. Some simple Googling of key phrases i.e. *package* security vulnerabilities will usually bring up more results than you’d expect. It’s also worth checking out the Issues tab on the package’s GitHub page. Vulnerabilities are often discussed there and you’ll be able to act accordingly. This applies to the top-level Package Managers too.

---

🚀 Sign up for The Replay newsletter

The Replay is a weekly newsletter for dev and engineering leaders.

Delivered once a week, it's your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.

Over 200k developers use LogRocket to create better digital experiences

Learn more →

---

Package managers are used by almost ALL of us. If you really want to scare yourself, go ahead and search *package manager* security vulnerabilityand take a look at all of the results! Again, knowing what we are installing and granting permissions to, and especially keeping a note of this, could just save our Bacon.

Handy tip: if you want to know which hooks an npm package runs, before you install it, run the command:

npm show $module scripts

HTTPS EVERYTHING!

I’m sure you’re already familiar with what HTTPS means and why it’s become the standard for web traffic. That being said, many Devs still don’t use SSL/TLS Certificates on their web apps — even the most data-sensitive ones.

In the early days, buying a certificate from a Certificate Authority meant spending hundreds of Dollars, and a complex setup process. Now, certificates are not only much easier to setup, but also much cheaper — i.e. free of charge.

A couple of years back, a service called Let’s Encrypt launched to become a new Certificate Authority, issuing secure SSL/TLS certificates, free of charge. Let’s Encrypt is part of the Linux Foundation, and backed by super-companies such as Google, Facebook, Cisco and Mozilla.

So — there’s no excuse not to — Head over to https://letsencrypt.org/ , and grab yourself a free SSL/TLS certificate.

Preventing XSS & Request Forgery

Cross-Site Request Forgery & Cross Site Scripting are two of the biggest security vulnerabilities in web applications, that while obvious, still cause the most amount of trouble.

Many Devs believe that XSS & CSRF will automatically be taken care of by the server & framework they choose — but that isn’t the case. Happily, there are simple fixes that are easy to implement.

Firstly, use both the HTTPOnly and Secure attributes when setting session cookies. The HTTPOnly attribute prevents the cookie being accessed by client-side scripting. The Secure attribute ensures the Cookie will be sent over an HTTPS connection. (Ensure you’ve addressed the HTTPS EVERYTHING point above, first.)

In Node, if you use Express.js; the above can be achieved with the following:

var session = require('express-session');

app.use( session( {
  secret: 'secret-key',
  key: 'sessionid',
  cookie: {
    httpOnly: true,
    secure: true
  }
} ) ) ;

Secondly, install and use the npm package ‘Helmet’. This mitigates almost all XSS and CSRF attacks and is easy to implement. Check out the package here and follow the checklist they provide.

Use Logging & Log Analysis

Logs are essentially the private diary of your application. So long as they’re setup to record, you’ll forever have a copy of every important event that occurs on your servers — but many Devs still completely ignore them or don’t utilise them to keep track of security issues.

I understand that reading through endless command-line outputs isn’t everybody’s idea of a fun time, and getting the right balance of what to actually record in the logs is something of a mystery to many. However, logs give us a solid record of events that we can rely on to inform us to any malicious behaviour, as well as giving us a complete insight into our telemetry.

There is still an obvious, but major issue here though, in relying on logs for Security purposes — logs are only going to tell us of a malicious event once it’s already happened. And if we only periodically tail our logs, then we’re going to miss whatever information was important at the time anyway. The other obvious issues lie in exactly how much data we are going to record. If we have a particularly busy service, our log files will be enormous and very difficult to query. Especially seen as we don’t actually know what we’re looking for yet, and our logs don’t contain much realtime context.

There are a whole host of Log Analysis tools available to help make sense of your logs. From experience, I’ll focus on just two:

If you are willing to run your own Log Analysis tools, then I would strongly recommend the ELK Stack . ElasticSearch, Logstash & Kibana. This stack is something I used in production for years, and it was truly remarkable. This stack will run and work for an App of any size, but due to it’s slight resource intensity it’s better for slightly bigger applications, when you have a lot of data being recorded.

It used to be fairly labour-intensive to setup an ELK Stack, but thanks to all of the automation tools that I complained about earlier in this article, it’s easy! If you’re a fan of Docker , you can use Docker-Compose to setup an ELK Stack very quickly. Take a look at this GitHub repo, and follow the instructions on there. You should be up and running fairly quickly!

It’s worth noting at this point that one of the big bonuses of using Log Analysis, is being able to be notified of incorrect behaviours in realtime. The above stack, by default doesn’t do this, but can do with plugins.

Get involved in Open Source

If you roll-your-own for most of your tech instead of using others’ Open Source libraries; the chances are the only people who will ever know that there are internal bugs / security vulnerabilities are the people internal to your team. While this might seem like the better option, in my experience it’s actually rather detrimental. If you work on a small team with few other Developers, the chances of you spotting these mishaps is much less.

By utilising Open Source software, and opening your software up to the Open Source world, you are allowing many more eyes to cast judgement and are therefore much more likely to find errors quickly. By opening up to the OS Dev community, you are also allowing others to submit patches to your software — lessening the workload on your internal Devs. I gave a talk on the Value of Open Source and you can see my arguments for this, there.

When opening up to the external Developer Community, it’s important that you make it as simple and secure a process as possible when asking them to report bugs and security vulnerabilities. Ensure you research a responsible security vulnerability disclosure policy that works for your team, and implement it. It makes things fair for both parties, and allows a set structure for these vulnerability reports.

If you work for a slightly larger company, it might be worth trying to wing some budget for a Bug Bounty Program . The idea here, is that you offer the Developer community small bounties for finding/patching bugs in your application. These bounties can be anything from $100 to the absurd $ 1million I once heard being offered. Many agree that offering a couple of hundred Dollars for a community member solving a problem for you is worth the thousands it could cost you, if it were to be exploited.

It raises the question — how much is your security really worth to you?

Follow the OWASP Top 10

There is a professional standards body aiming to improve web security for the better of us all. OWASP provide a Top 10 list of the most critical security threats to web applications, and it’s worth going through their data to apply it to your app.

Their 2017 list is currently in the process of being finalised — but you can find their (still fairly relevant) 2013 list here.

If you apply the knowledge shared in this article above, alongside the OWASP security list; you’re well on your way to mitigating any potential web app security threats.

Conclusion

All of the points above are my baseline standards for web app security, that I’ve come to advocate from personal experience. By addressing each point in this checklist, you have bases covered from prevention, to interception, to recovery. I realise that I cannot possibly cover every eventuality, and in fact, I haven’t gone into many topics in this one article.

This article is part of a 3-part series, aiming to cover the basis for good, and thorough web app security. Part 2 of this series will cover the Web Servers we all commonly use, including their pitfalls, security vulnerabilities and down-right dangers. Part 3 will cover Users, Authentication & Privileges — arguably the most common area for Security issues.

Stay tuned for the next 2 articles, and if you have any questions, please feel free to reach out — [email protected] !

• @rbin