![\"A](\"https://anderegg.s3.amazonaws.com/cves.webp\")
Gavin Anderegg · October 26, 2026
\nThe internet is becoming a more dangerous place, and fast. LLMs are only getting better at identifying security issues, and more people are taking advantage of this. Some people argue that LLMs will eventually make large-scale vulnerabilities a thing of the past. I’m not so sure. Either way, I think it’s a good idea to have less stuff that can be hacked online. One way to do that is with statically generated sites.
\nThis past week was a bad one for security issues. The most prominent one was PHP2Shell, which had PHP on the minds of non-technical folks — not a win for society. There was also Node2Shell, which exploited Node’s built-in Brotli compression stack. But there were a whole lot more.
\n
Note that the above chart is only showing critical CVEs. Here’s another showing all CVEs. When I last fretted about this in May, we were still doing rookie numbers. Things aren’t likely to get better any time soon.
\nIn my time, I’ve built a lot of stuff on the web. From the early 2000s to the mid-2010s, I specialized in building on top of content management systems (CMSs). For most of that time, there was a standard platform the team built with. This made sense for building larger sites, when people on our side would be doing much of the content work. In other cases, it was because “the client says they want to edit the site”.
\nIt’s very possible your clients acted differently than mine, but the number of clients who actually edited their CMS-based site was a rounding error for me. Instead, our team usually got site change requests via email. Maybe there was a gung-ho junior person on the client’s end who’d update things for a while, but it was almost always back to email once that person left. The only clients who routinely edited their sites were those with internal development teams. 1
\nMore recently, I’ve seen a lot of folks building massively complex Node-based contraptions with server-side components to power what are effectively static websites. Lots of SSR, hydration, and the like. There’s nothing inherently wrong with these strategies, but I’d argue that they’re overkill for content-focused sites.
\nIf you’re building a complex web app, you’re likely going to need a server in the mix. If so, you presumably have a plan to maintain it. Someone will have to apply security patches, but no one should find this surprising. On the other hand, if what you’re building is mostly static and content-based, you should ask yourself if it’s still worth it to use dynamic/server-side tooling.
\nHow often will that site’s content be updated, really? Do you have a plan to maintain the software it’s built on? Will there be a maintenance contract in place with the client to cover the time to patch things? I’m betting that web software is going to need ever more attention in the future. Patching your CMS- or Node-based site every six months isn’t going to cut it anymore, and clients may raise an eyebrow at the “security update” line items on their invoice. 2
\nWhat if, instead of all that, you just put some HTML on the web?
\nI got the idea of static site generators (SSGs) when I first heard of them, but it took a while for me to really get on board. When I switched this site over to Jekyll from toto in 2012, it started to click. What if all the interesting work happened at build time, and the output looked basically like a website from the 90s? That sure would be lightning quick and cheap to host! 3 In fact, this site is hosted for free on GitHub Pages, and has handled many large traffic spikes without breaking a sweat. The cherry on top is that I’ve never had to worry about applying security patches. 4
\nThough it’s a good case study for a static site, a blog isn’t all that interesting. 5 Same goes for a standard brochure website. But since getting on the SSG bandwagon, I’ve found many other uses. Client dashboard? If the data’s only changing every few hours, it’s often cheaper to generate a set of JSON files than query the database. Custom data visualization? Again, I’ve had very good results building an SSG into the ETL pipeline. Hugo has been a huge boon here because of its data source feature.
\nThere are other interesting examples in the wild. Cloudflare has had their documentation on several flavours of SSG throughout the years. V&A wrote about their SSG transformation. Fastmail documented their move from WordPress to Eleventy. For larger organizations, SSGs can save a lot in hosting costs. I think they’ll also be saving ever more in security and maintenance.
\nBut this stuff isn’t just for nerds. Publii is a great, free, and open-source tool that can be used to graphically generate a static website. Also, I shouldn’t discount hosted services like Bear Blog, Pika, or Micro.blog. If you just want a place on the web without worrying about security issues, having someone else worry about that stuff isn’t a bad idea, either.
\nI don’t want to come off the wrong way here. There’s nothing wrong with building dynamic software on the web. The point is: much of the web is mainly static anyway. Static sites are blazing fast, effectively free to host, and offer only the tiniest security footprint. If you’re likely to get changes via email, you can save yourself (and your client!) some potential headaches by using a static site generator in the first place.
\nOriginally published at anderegg.ca.
","headings":[{"level":1,"text":"Just put some HTML on the web","id":"just-put-some-html-on-the-web"}]}}