Static Sites: The Ideal Security Blogging Platform

Juggling Priorities

It should come as no surprise that, when building this site, my first concern was security. This arose partially from the fact that I live and breathe cybersecurity and believe (not without cause) that the whole internet is out to get me. However, it’s also true that sites focused on cyber issues tend to present attractive targets to hackers attempting to prove their skills and gain some renown with people who might actually appreciate their accomplishments.

Building a secure application is always a balancing act between locking everything down and providing a feature-rich experience to the end user. For example, I could maintain a very secure blog by hand-writing posts on a sheet of paper, biking to a random telephone pole each morning, and stapling my blog post to it. Barring the site of me struggling uphill on my bike attracting the attention of an untoward mugger, this approach to blogging is virtually risk-free.

Alternatively, I could provide my users with SSH keys and sudoer accounts to my server and let them write fully featured comments in .php and display them right on the site. This would constitute a more or less unrivaled feature-density for a blog but would also cause quite a lot of trouble for the innocent victims who happen to visit my site.

The appeal of all-static

For me, the end objective in building a secure blog was to get as close as possible to the ‘sheet of paper pinned to telephone pole’ approach while still taking advantage of this internet thing and making a somewhat respectable looking site for myself.

To this end, static sites are great. They serve a handful of files to the client browser and then everything else from how the site looks to how it behaves is up to the client.

The downside of static sites is that they tend to look like they were made in 1995 and are a pain to update change since boilerplate code must be repeated on every page and edits require interacting directly with the HTML.

Enter static-site generators like Hugo, Jekyl, Hyde, Brunch, Punch, Grain, etc.

Despite the fact that you can pick almost any 4-5 letter noun and find a corresponding static site generator, static sites made by these tools constitute a miniscule portion of the net’s inherently static content. Indeed, tools like Drupal, Joomla!, and the all-powerful Wordpress dominate web content and tend to open users up to risks they don’t really need to take for the content they’re serving.

Modern site generators like Hugo (which builds this site) support many of the useful features folks have come to expect from CMS applications and webapp servers. I can define templates so all of my posts and pages look the same. I can write my text using markdown instead of html. I can even automatically generate lists of related posts, hide posts while I’m drafting them, and include custom content in every template.

Static sites are also extremely performant. At the time of this post my entire blog is less than 2MB (outsource the image files to a free hosting site and that’s less than 200KB). This content is cache-friendly, inherently easy for search engines and screen-readers to navigate, and painless to backup and deploy.

As an added bonus, I can stick my site on services like Github pages, or in an Amazon S3 bucket. These services are the equivalent of internet telephone poles. They’re cheap (or free), publicly visible, and delightfully impersonal. I don’t have to worry about keeping them updated, applying the latest security patches, tracking CVEs, or sanitizing user inputs. I just shout out into the void and anyone can choose to listen however and whenever they please.

Downsides

The cost and security benefits of an all-static site don’t come free, of course.

The biggest trade-off is the loss of interactive and persistent applications. Although localstorage and javascript allow for some pretty robust client-side functionality on modern browsers, nothing can rival a full-fledged server with a database when it comes to serving dynamic data.

Furthermore, the initial jump to static sites is a little tougher than simply installing a CMS. There’s an overwhelming range of options and it’s hard to judge which offerings will maintain community support in the distant future and which will be abandoned. Each static site generator has it’s own conventions and practices and they take time to pick up - even if you’re coming from a web development background.

Finally, static sties require internal trust. There’s no inherent access controls or permission levels for multi-editor sites. Anyone on the editorial team can stick content anywhere without issue. Although there are ways around this (see my upcoming post on security strategies in static site generation), it represents a pretty hard-hitting feature loss when compared to robust CMS products on the market.

Recap

Static is the perfect fit for a site like this - one which revolves around serving content, giving me the power to customize as I see fit, and remaining fast, affordable, and secure. It’s not the perfect choice for every website, or even every blog, but it strikes a good balance and tends to be an under-appreciated option.