This website is built with Hugo

We use all manner of tools here at Punk Security, and we always ensure we choose the right tool for the requirement.

Hugo is an opensource framework for generating sprawling, but static websites. It allows you to write content for your website as easily as writing a text document. This means you can have the benefits of a dynamic website, but all of the sites pages are actually static and therefore have no database to support them.

With no database, we reduce the risk of attack and speed up every interaction with the site. Doesn’t that sound like a good thing!

What is a static website?

Website pages are really just files and scripts which are sent to your web browser from a server. Files like images are almost always static, they exist on the server and are then served to the browser, but the websites pages themselves are very often built on the fly by the webserver. This makes total sense, Amazon doesn’t want to write millions upon millions of pages because of all their products! Instead, they write one page and then swap the bits out for each product.

Dynamic websites are great, but the dynamic generation of pages is one of the main reasons that websites get security vulnerabilities. If a web server is building me a unique page based upon the product I’ve asked for, maybe I can look under the bonnet and make a special request that causes it harm.

When the web server goes a fetches some product specific information, such as the price or description, this takes time. Too many of these lookups, and you have an awfully slow website.

A static website does all this effort up front. We don’t actually use a database at all, as everything is stored in little configuration files, but the same principal applies. Instead of the webserver building each page as it is requested, we build all our pages into the files ready to be shipped to the user when they need it. This doesn’t scale to a website with a million products, but can easily accommodate a website with a thousand blog posts. It also means our site content can’t change that often, we would have to run a rebuild job to make even a single typo correction.

Static websites are blazingly fast, and for a website like ours they make perfect sense. Static website generators, like Hugo, are surging in popularity right now. The websites they build are faster, safer and cheaper to run.

How do you build a static website?

Hugo allows us to run a website from our PCs and laptops, using a built in webserver. Every time we make a change to our website configuration, this website is rapidly rebuilt and we see those changes in under a second. This makes making changes really easy.

To release the website, we need to do something a little more complicated. We have to generate the static files with Hugo, upload all the static files to our Amazon s3 bucket and then tell Cloudflare to reset our cache. Cloudflare isnt a requirement for a static website, but it makes our site even faster as its hopefully being served from a Cloudflare server near to you, rather than our s3 bucket in Manchester.

In actual fact, its a little more complicated than that. First we build our website to our staging site, which is an identical setup but allows us to verify that the website is going to build correctly. We then repeat the process for our actual website.

In actual fact, its even more complicated than that! With hugo you can set the date for a page update, and it won’t generate it until that date. That means we can write a blog post, like this one, and have it hidden until the we want it released. Unfortunately, being static, to release the page we need to do a build after the release date in the configuration. So we also now need to make sure we build all future pages on our staging site and then do a nightly build on our actual website. This is exactly what we do, automatically. Enter source control 🛠

Automating the build

We use Github for our source control, and we sue Github actions to automate the build process for our website.

When someone here at Punk Security wants to make a change to the website, they propose a change to the website by submitting a change to our website with something called a branch and a pull request. Automation then runs the Hugo build, updates our staging AWS s3 bucket and purges our Cloudflare cache. Our colleagues are then notified by Teams, and provided with the weblink to our staging website so they can review the changes. When one of our colleagues then check and approves the change, the automation picks right back up and modifies our actual website. Doesn’t that sound much easier!

With all our configuration being approved, we then run a nightly build to keep things up to date and release those future pages as they are scheduled.

The benefits of source control

Source control brings a lot of value to our deployments as it allows us to ensure that all changes are auditable, and the git change history does this for us. When we need to change our website, we modify our configuration in plaintext and then submit our change to source control, but before the website receives those changes they must be digitally signed and peer reviewed.

• Digital signatures
  All of our amendments need to be digitally signed, giving us confidence that it really came from that team member, and provides non-repudiation to our audit logs.
• Peer reviews
  All of our changes must be reviewed by at least one other team member, ensuring they are well thought out and not malicious. This has been proven very effective in reducing the insider threat and the principle of dual control is heavily utilised in regulated industries such as Finance.

We also get a raft of other features out of the box; such as centralised access control, offline working, trivial rollback of changes and of course that full and transparent audit log.

Our web architecture

We store all of our files in Amazon AWS s3 buckets, which are a file based cloud storage system from Amazon. We use this service because its reliable and cheap, in fact we often stay inside the free tier, and it has great programmatic access. There are plenty of website hosts available, but they almost always have clunky ways to access them.

We could just use s3 to serve our website, but instead we tell our users to go to Cloudflare first and then it goes onwards to s3 for them. This gives us a few great benefits:

• Amazing web caching
  Cloudflare will fetch the content of our pages once, and then store them in its cache. This could be a nightmare for a website which changes often but its absolutely perfect for us as we can just flush this cache when we rebuild. This cache is then served to the user from a place near them. Our clients in the UK, in Europe and in the US all get the exact same experience.

• It optimises our website Cloudflare knows how to make a webpage load faster, and it changes our website on the fly. The code that makes up a website page is very often full of spaces and new lines to make it more readable to humans, but sending this to a suers browser just wastes bandwidth and time so Cloudflare gets rid of it. It also compresses our website and images, making them smaller, and serves images appropriate to the devices size so we don’t end up sending huge images out to users with tiny screens.

Lets not forget LetsEncrypt

Our website certificate and encryption is handled by Cloudflare, but its provided by LetsEncrypt. LetsEncrypt is awesome ♥. It wants all the web traffic on the internet to be encrypted and safe from prying eyes, so it gives out FREE certificates in a completely trivial and automated way.

For more information, email us at [email protected] or call us on 01609 635 932