Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1

Following on from our previous security post, everyday security tips, we’ve compiled a list of security guidelines to follow when building and deploying an application. We can advise and help you with these solutions.

Serving secure websites/applications

* Always serve over HTTPS

Search engines rank https:// sites higher than insecure http:// sites (Official Google Webmaster Central Blog: HTTPS as a ranking signal), and as of July 2018, Google Chrome will start marking non-https sites as insecure (Google Online Security Blog: A secure web is here to stay).

You should also often ensure that your HTTPS configuration is up to scratch, you can do this using either Qualys SSL Test or testssl.sh.

* Set secure headers for browsers

There are various headers you can specify for a modern web browser to use when interacting with your website. These headers tell the browser about how to interact with your website securely, ranging from enforcing https:// on subdomains with HSTS (HTTP Strict Transport Security) to specifying where to allow content to come from e.g. only load images from your domains CSP (Content Security Policy). You can verify that these have been configured on your website using securityheaders.io.

* Set the secure cookie flag for session data

If your application uses cookies for sessions or any personal data, make sure to set the secure cookie flag so that the browser only sends the session cookie over a secure connection back to the server. This increases security by helping protect against session hijacking.

Authentication and Privacy

* Store passwords with a slow cryptographic hash function

To help protect passwords from being stolen if a database is leaked, you should store passwords as hashes with salts. To authenticate, rehash the given password and compare the result with the stored hash. We recommend the bcrypt cryptographic hash function as there has been no effective crypt-analysis published since its birth in 1999, showing its maturity. Make sure to not use the password’s pre-cryptographic-hash in any other parts of your application (CynoSure Prime: How we cracked millions of Ashley Madison bcrypt hashes efficiently).

* Aim for forward privacy

Forward privacy describes a way of storing data so that no personally identifiable data can be derived from stored data, even when combined with external data. For example, consider a hospital sharing medical patient information, stripping out their usual identifiers (name, address, etc.). If the person has a unique medical condition that has been mentioned elsewhere, their privacy could be breached.

Infrastructure and DevOps

* Reduce the attack surface of servers

Your servers should only have and expose the programs and libraries required to run your application. This greatly reduces the number of entry points for an adversary to compromise your application. Docker helps achieves this by enforcing you to only run a single process or supervision tree in containers, almost like a Unikernel system.

* Use Firewalls

Configuring firewalls on your servers and networks helps filter out unexpected, potentially malicious, traffic to and from your servers.

* Follow the principle of least privilege

The principle of least privilege describes how a program or user should only be given the minimal amount of permissions to fulfill its purpose. This helps reduce the impact of a service being compromised as an adversary would only be able to act with the same permissions of the service.

* Incorporate Demilitarised Zones (DMZ)

A DMZ refers to a private network (not exposed to the internet) where private services can live. These private services are often databases, caches and service workers which shouldn’t listen to traffic from the internet. By utilizing DMZs, you can focus more efforts on hardening exposed services.

* Use bastion host(s)

A bastion host serves as a critically strong point in a network. They are commonly used as gateways into an application and so are often exposed to hostile elements and therefore configured to withstand them. Properly configuring an AWS Load Balancer can serve effectively as part of a bastion host providing the target instances are also hardened.

Think we can help? Get in touch.

Looking for a partner who can create beautiful digital products whilst keeping your customers' data safe? We'd love to talk to you.

Share: