Let’s face it—modern web apps are complex. And given that complexity and security can be like oil and water, keeping your digital assets out of harms way is no easy task.
But where there’s despair there’s hope. And in most cases, making your web app static can improve your overall security posture.
By reading this article you will learn:
The attack surface is the sum of all entry points that an attacker can use to compromise your system. For a web app, the attack surface can include a search field that accepts user supplied data. The attack surface also includes how the underlying web server is configured. Other other examples are out-of-date and unpatched CMS software and website plugins.
Consider a hotel vs. a bunker: guests, employees and pretty much everyone else can enter the hotel using the main door, the underground garage or by smashing a window. The bunker probably has a single well-guarded entrance, and breaking in to the bunker by hammering a window is impossible since windows are not part of the bunker’s surface. Simply put: the bunker has a smaller attack surface than the hotel.
Static sites are probably the most basic web product you can think of. And back when the web was just a kid, the static site was all we had. They consisted of HTML files, maybe a few images and possibly some styling information. Probably no one called them static sites back then. They were just sites. But as the need for dynamic content and user interaction grew, web developers moved towards languages like PHP for server side rendering to improve both usability and value for their users.
Static sites have one major advantage over their dynamic counterparts: speed. When a browser requests a static site, it does not have to wait for any backend database connections or scripts to be run before the user can see the webpage.
Let’s say you run a very popular blog. Your backend database is packed with thousands of blog posts. Every time a user wants to read one of your blog posts, a database connection is made between the web page and the backend. While there’s nothing wrong with this architecture, taking the database out of the equation will do two things: speed up your site and prevent hackers from using vulnerabilities in your database setup to compromise your site. Removing the database from the attack surface also protects you from falling victim to common implementation vulnerabilities like Cross-site Scripting (XSS) and SQL injections.
Long story short: use a static site generator. Most static site generators are language specific. For an example, read my blog post on how to generate a static site from a Contentful-powered web app written in Python. But no matter if your app runs on NodeJS, Ruby or Go, the underlying principle of how static site generators work is the same.
Going back to the blog example — a static site generator would generate a static page for every blog post, together with tags and categories, by pulling the information from the database. The generation of the static will take some time — but once generated, your users will thank you for your optimization efforts.
The flat and static files generated by a static site generator can be deployed almost anywhere. All you need is a provider that can serve users HTML files — something everyone can do. Having someone like Surge.sh or BitBalloon to host your static files will almost always be cheaper than using a "full-stack" provider like Heroku.
A Content Delivery Network, or CDN, is a global network of servers. A CDN provides minimal content delivery times together with top class uptime. The main idea of a CDN is that when a user requests a web page, the webpage is loaded from a CDN access node that is geographically close to the user — therefore keeping delivery times short. Also, a static file is easily cacheable, so using a CDN for your content will ensure a smooth user-experience.
Imagine not having to worry about backend database connectivity. With static sites, your users will no longer risk seeing a "Database connection failed" message when visiting your site. Running it all static, together with a CDN, is a good preventive measure against DDOS attacks. Because if one CDN node gets DDOSed, another node will take over in no time — and your users won’t notice a thing.
Wouldn’t it be great if we could just wave a magic static site wand over our code and production environment to make it 100% secure? It sure would, but the reality is that very few modern web apps could be made entirely static and still remain useful.
Take user comments for example — a common implementation is to take the user supplied data, validate it from a security point of view and store it in some type of backend database. In this case, making your web app completely static would mean we would have to get rid of the user comment functionality altogether — probably not what you want.
Are you ready to dive in and create a Contentful-powered static site with the static site generator GatsbyJS? If so, our very own Khaled has created a four part video series on how to get started. You can also find the source code on GitHub] and read A Beginner's guide to creating a static site using React, Gatsby, Contentful and Netlify
Additionally, we also have a gatsby-contentful-starter repo for you to clone to get your first Contentful and Gatsby-powered blog up and running in no time.
Static sites can be used to reduce the attack surface of any web app or website. A smaller attack surface, and gaining control over your attack vector, makes it harder for digital vandals who are up to no good and attempting to break your site.
Static websites are created by static site generators. The end result is a collection of flat and static files that can be deployed to almost any hosting provider for little or no money. Static sites are fast, reliable and work great together with Content Delivery Networks.
Want to build a static site with Contentful? Request a demo and see what's possible.