Last night I went to check on this blog, and Drupal was dead. It was showing a message saying “something is wrong with the site” with no particular explanation as to why it was down. Odds are good that someone attempted an exploit that was only partially effective, enough to crash the service without being enough to take it over completely. This was the last straw. Out with Drupal and all of its security holes!
It’s been a long time coming. I don’t want to pick on Drupal in particular, because among CMS options, it’s one of the more flexible and well written. The major alternative today, WordPress, has seen its share of security holes as well. Due to its popularity, WordPress is likely even less safe than Drupal, since it’s a more juicy target to exploit.
In fact, despite the amount of support WordPress gets from its massive community, the truth is that, with any dynamic CMS like WordPress or Drupal, you really have to be constantly vigilant. And even that isn’t enough to keep you safe with periodic zero day exploits on WordPress and Drupal both.
Running a dynamic CMS based on an insecure-by-design language like PHP is just going to be fraught with emergency “need to patch the site!” interrupts, no matter what CMS you choose. Just about every feature of the CMS is another possible attack surface. Every plugin you add will similarly open new potential security holes.
But with a static site generator, the attack surface area is tiny and well constrained:
- Your ssh server
- Your http server
If you host on Amazon S3 or another service, then both of these are managed for you as well1. And believe me, Amazon is far better at security than 99% of the people who run Drupal or WordPress sites, myself included. As an Amazon employee, I came to respect their security practices, and I’d rather they handle my security than trying to do it all myself.
It’s true that if your site is more complex – say it requires user login – then you’re adding more APIs that need to be secured. But in that case the attack surface area is well constrained: You just have to verify that your API is secure. For most APIs you can use a form of fuzz testing to verify that there aren’t obvious ways of breaking or exploiting the service.
And smaller APIs can be written easily in a language like Go, for increased speed and security relative to using PHP or even NodeJS. And much of the non-critical logic can run in the web browser, where a bug won’t mean that your server gets compromised.
The “new name” for this architecture is JAMstack, but it seems to me to be the right way to build web services in the 21st century, no matter its name. There are many static site generators that can be used to build sites like mine; I’m a fan of Go, and I decided to try Hugo as a result. As of late last night, this site is generated by Hugo.
Long live Hugo!
- EDIT to add: In a Quora discussion about a similar security claim, a commenter pointed out to me that you can potentially hack Amazon S3 by finding the access keys in an unprotected place, by social engineering, or by compromising a server that stores the access keys in an insecure manner. These are also all attack vectors for any WordPress or Drupal site, though, so I still consider static site generation to be strictly better. There are also solid security practices that will prevent any of these attacks from succeeding or doing any damage. [return]