A Static Site Has Nothing To Break Into

Nothing Runs When You Ask For A Page

This week the PHP project shipped fixes for PHP2Shell, and its advisory said the attack can fire “before any application code runs”¹. I wrote about what that means for PHP in PHP: Twenty-Nine Years Of Leaving The Door Open. This post is about the other half of the answer. What if nothing runs at all?

That is how this blog works. When you asked for this page, no program of mine started up, read a database, checked a login or built any HTML. A file that already existed was sent back. That is all.

Here is what that difference looks like, measured on the same day, against a stock WordPress installed fresh in a lab and against this site as it is live now:

None of those zeroes is a setting I switched off. They are zeroes because the thing they count does not exist here. You cannot attack a login page that was never built.

What A Stock WordPress Puts On The Internet

I did not want to argue this from memory, so I measured it. The official wordpress and mariadb container images, run in podman on my own machine and bound to localhost, installed with nothing added: no plugins beyond what ships, the default theme, one administrator. WordPress 7.1.3 on PHP 8.3.36. Then I counted what it answers.

The REST API is the biggest single surface. Five namespaces, 133 routes, 257 route and method pairs, and 62 routes that accept a write of some kind. It shipped in core with WordPress 4.7, “with REST API endpoints for posts, comments, terms, users, meta, and settings”². And you are told not to turn it off: “You should not disable the REST API; doing so will break WordPress Admin functionality that depends on the API being active.”³ So it stays on.

The users list is worth a second look. In my lab, an anonymous request to that endpoint returned the one administrator account, by display name and slug. Somebody who has never logged in learns who the site’s accounts are before they have tried anything, on a fresh install, by design. Nobody had to misconfigure it.

Then the files. The official image runs Apache as www-data, and www-data owns the whole web root. All 3,785 files, the 1,514 PHP files among them, are writable by the same user that runs the code. Every file. The code included. wp-config.php, with the database password in it, sits in the web root at mode 644. The database account WordPress uses holds ALL PRIVILEGES on its database.

That is the one-process model from the PHP post, live and unmodified, from the official image. It is not a badly run site. It is the starting point every WordPress site begins from, before the first plugin goes in.

And plugins are where most of it comes from. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025. “91% of new vulnerabilities were found in plugins, and 9% were found in themes. There were only 6 vulnerabilities reported in the WordPress core.”¹⁰ Nearly half had no fix by the time they were made public, and the median time to mass exploitation for the ones attackers wanted was five hours¹⁰.

What This Site Puts On The Internet

This blog is 6,343 files. Here is all of it, by kind:

There are a few .py and .sh files in there. They are scripts attached to posts for readers to download, and the server sends them as text. Nothing on the server runs them. There is nowt on the server to run them with.

It is deployed to Cloudflare as static assets with no Worker script at all. The deploy configuration has no entry point, and Cloudflare’s documentation says what that means: “The main key is optional for assets-only Workers.”¹¹ When a requested path matches a file, “that file will be served” without invoking Worker code, and “If no Worker script is present, a 404 Not Found response is returned.”¹² It costs nothing either: “Requests to static assets are free and unlimited.”¹³

Cloudflare is a choice, not a requirement. The output is a folder of files, and any HTTPS server that can send a file can serve it: nginx, Caddy, an Apache serving nothing but static files, or an object storage bucket behind a CDN. The links are relative, so the same build serves unchanged from a domain root or from a subdirectory; that was checked by serving the built site under /preview/ and confirming all 592 local references on six pages resolved. Moving host is copying a folder. The one Cloudflare-specific piece is the _headers file; anywhere else, the same headers go in the server’s own configuration. What carries over is the property that matters. Whatever serves it only has to send files, so it never has to run your code.

So the live site answers like this:

$ for m in POST PUT DELETE; do curl -s -o /dev/null -w "$m %{http_code}\n" -X $m https://blogs.damiendye.uk/en/; done
POST 405
PUT 405
DELETE 405

$ for p in wp-login.php xmlrpc.php wp-admin/ wp-json/; do curl -s -o /dev/null -w "%{http_code} $p\n" https://blogs.damiendye.uk/$p; done
404 wp-login.php
404 xmlrpc.php
404 wp-admin/
404 wp-json/

Nothing answers. That is the design.

The security headers go out with every file from a plain text _headers file in the repository, which Cloudflare reads at deploy¹⁴. The Content Security Policy locks every script, style, image, font and connection to this one origin. I will be straight about the gap in it: script-src and style-src still carry 'unsafe-inline', because the theme writes a few small scripts into the page. It is the outstanding job on that file, and it is written down in the repository as exactly that.

And publishing does not need a door. On WordPress, publishing is a write over HTTP: the editor, the REST API and XML-RPC exist because that is how posts get onto the server, and every one of them is a path in. Here, I write a post as a text file and push it to a Git repository, and the build uploads finished files through Cloudflare’s deploy API. Nothing that serves the site accepts a write from the web, because nothing needs to. The repository is private, too. Ask GitHub for it without my credentials and the answer is a 404, so the source, the drafts and the history are not on the internet either.

Attack Surface Is A Count, Not A Feeling

OWASP defines the attack surface as “the sum of all paths for data/commands into and out of the application, and the code that protects these paths”¹⁵, and says the way to shrink it is “turning off features and interfaces that aren’t being used”¹⁵. The UK’s National Cyber Security Centre puts it more bluntly: “If would-be attackers can’t reach an interface, they can’t attack it.”¹⁶ Its Cyber Essentials scheme makes it a requirement: “remove or disable unnecessary software (including applications, system utilities and network services)”¹⁷.

So count the paths, by what they are rather than by how many:

Nine rows. Not one of them runs code on the server. Every one of them for the same reason. The work was done before anyone asked for a page.

That last-but-one row is the honest catch, and the rest of this post is about it. A static site still runs code. It just runs it somewhere else, once, before publishing.

How Hugo Keeps The Build Honest

Hugo is “a static site generator written in Go”¹⁸, so the program doing the building is itself memory safe and compiled, which matters after the PHP post. Its security page draws the line exactly where this post does: the output “runs directly in the browser”, but “during development and site building, the hugo executable itself is the runtime environment.”¹⁹ And on serving, plainly: “We have no online production server”¹⁹. Good.

Within the build, it is locked down by default. “Hugo’s built-in security policy, which restricts access to os/exec, remote communication, and similar operations, is configured via allowlists. By default, access is restricted.”²⁰

This site widens one of those on purpose. It adds the CI commit variables to funcs.getenv, so the build stamp at /en/version.json can record which commit built the live site. That is a choice made and written down, which is the point of an allowlist. As such, it is not a hole. It is a decision.

Where The Risk Moves: The Build

Take the server out and the risk does not vanish. It moves to whatever builds the files. The SLSA framework names the two threats exactly: a “build integrity threat”, where an adversary introduces “behavior to an artifact without changing its source code”, and a “dependency threat”, by “compromising some other artifact that the former depends on at build time”²¹.

This site is in the middle row, and I am not going to pretend otherwise. It builds in Cloudflare’s build container on every push to the repository. That container is not the server that answers you, and it is gone when the build finishes. But for the length of the build, it is trusted with everything that ends up on the site.

And the build had two gaps, both of which I found writing this post. One is fixed. One is a choice.

The first is the kind of thing you only find by reading your own build script line by line. The script did check the version. But a version string is something a binary says about itself. It proves nothing about the bytes. Now the bytes are checked:

Fetching Hugo Extended 0.167.0...
Hugo verified: sha256 0163f5c3deddac1f494a1629ddc40c65d18de9d5794facd98f7f96ac2c7d8957

And a copy of the same tarball with one byte added is refused:

Refusing to build: hugo_extended_0.167.0_linux-amd64.tar.gz does not match the release checksum
  expected 0163f5c3deddac1f494a1629ddc40c65d18de9d5794facd98f7f96ac2c7d8957
  got      92682d765d9d34bc53d6f818d56e598d34b5b8267a1cc3b9971da0f53c792251

The theme is a deliberate trade, currency over reproducibility, and it is written down as one. But it is exactly the dependency threat SLSA describes, and the honest thing is to say so. Neither gap ever exposed the live site to a visitor. Both were trust placed in the build, and I would rather list them than have a reader find them.

Even the checksum has a limit. It proves the file you downloaded is the file on the release page. It does not prove who put it there: there are no signatures among the release’s files²². That is integrity, not authenticity, and it is the most the project offers today.

Building It Offline, Once

The strictest version takes the build off anybody else’s machine. Build on a machine you own and control, check what you built, and upload only the finished files. Nothing on the internet ever runs your build, and the host never sees anything but output.

That is a few commands, not a project. And it changes where an attacker has to be to hurt you. To change a WordPress site, they need one request to the server. To change this kind of site, they need your build machine. That is a much smaller target, and it is one you can unplug.

Ten Thousand Pages, Measured

Attack surface is one cost of running code on every request. The electricity is another, and so is the disk. So I put both under the same load: 10,000 requests for the home page, ten at a time, from the same laptop, over plain HTTP on localhost so neither side paid for TLS. The stock WordPress from the lab on one side. On the other, this site’s real built files served by nginx in a container, because Cloudflare’s edge is not something I can put a meter on. I read the CPU time each container used from its cgroup before and after each run, three runs each.

That is two to three and a half thousand times the processor time for the same ten thousand pages. Every one of those CPU-seconds was drawn from the wall and turned into heat. The static side served all 10,000 in roughly the processor time WordPress spent on three or four of its pages.

The disk tells the same story:

The WordPress figures are a fresh install with one sample post. The static figures are this entire blog.

To be fair to WordPress, a full-page cache plugin would close much of the CPU gap. But look at what that fix is. It is a static copy of each page, put in front of the PHP so the PHP does not run. The cure is the thing this post is arguing for, bolted onto the side of the thing it is arguing against, with the login page, the API and the database all still there behind it.

What You Give Up

The honest list, because a static site is not the right tool for everything:

If you need a shop, a members’ area or user accounts, you need something running on a server, and this post is not telling you otherwise. What it is telling you is that a blog, a brochure site or a set of documentation does not need any of that. Most WordPress sites are one of those three. Be honest about which yours is.

Build It Once And Serve It Dead

What gets me is how much risk gets carried for no reason at all. A company page that changes twice a year, running a database, a login page, an API with 62 writable routes and a scheduled-job runner that fires every time someone visits. All of it there to produce the same HTML it produced yesterday. Every day.

That is not a technical decision. It is a habit, and it is a habit somebody bills for. Hosting, plugins, security add-ons, the clean-up when it goes wrong. What it is priced at is a managed WordPress plan. What it costs is every one of those paths kept open, and patched, and watched, for content that could have been a folder of files.

The standard I hold this site to is simple. Nothing runs that does not need to. Every gap is written down where the next person will find it, including the two in the build, and one of those is already closed. That is not about being clever. A standard is the thing you keep when nobody is checking, and nobody checks a blog until the day it starts serving somebody else’s code.

So build it once, check what you built, and serve it dead. Whatever is left to attack is on your machine, where it belongs.