Why we build websites that cannot run code

On 21 October, two flaws were patched in PHP. Both scored 9.2 out of 10. Both let an attacker run their own code on a web server without logging in to anything.

PHP is the language a large share of the web runs on. If your website is built on one of the common platforms, it is almost certainly running PHP every time somebody opens a page.

The detail worth noticing is where the flaw was. It was not in a plugin. It was not in a theme, or a contact form, or something somebody bolted on. It was in PHP itself, the engine underneath. Every site running that engine inherited the problem at the same moment, no matter how tidy the site on top of it was.

That is the part that does not get said often enough. You can keep a site immaculate and still be exposed by something three layers below you that you have never heard of.

What it means to run code on every page view

Here is the thing most people are never told about how their website works.

On a lot of sites, nothing you see exists until you ask for it. You click a page, and the server wakes up, runs a program, asks a database for your words and your photos, assembles a page out of them, and hands it over. Then it throws it away and does the whole thing again for the next visitor.

That program is the attack surface. It has to accept whatever a visitor sends it, make decisions about it, and run. Every plugin adds more of it. Every theme adds more. And under all of it sits the engine, which is where last week’s flaws were.

None of that is incompetence. It is a reasonable design that solves real problems, and a lot of the web is built on it for good reasons. But it comes with a standing cost: you are running software, so you are responsible for patching software, forever, including the parts you did not choose and cannot see.

What we do instead

Our sites are files.

The pages are built once, when we change something, and what sits on the server afterwards is the finished page. When somebody visits, they are handed a file. Nothing runs. There is no program to trick, no database query to interfere with, no engine underneath doing work on behalf of a stranger.

A file cannot be exploited. It can only be served.

That is why last week’s news was not a late night for us. There is no PHP on our clients’ sites, so there was nothing to patch. The same was true of the one before it, and will be true of the next one.

It also tends to be faster, because the work was done before anyone arrived, but that is a different article.

What this does not protect you from, because somebody will ask

I would rather say this than have you find it out from someone else.

Static does not mean invulnerable. It means a much smaller surface, and it is worth being precise about what is left.

Your domain can still be hijacked if someone gets into your registrar. Your hosting account can still be taken over if the password is weak and there is no second factor. Anything that accepts input, a contact form, a checkout, a login, is still a door, and doors need building properly whatever the rest of the house is made of.

And our own sites are not completely free of moving parts. Clients who edit their own content have an editor with a login and a database behind it. The shops take payments. Those pieces exist, and they are the parts we spend security effort on.

The difference is that they are small, specific, and separate. A flaw in one of them affects that one thing. It does not hand somebody the whole website, because the website is not a program. It is a folder of pages.

That is the actual claim, and it is the one worth making: not that nothing can go wrong, but that the number of things that can go wrong is a fraction of the usual, and the ones that remain are ones we chose and can see.

What to do if your site does run on PHP

Not a sales pitch. Three things, in order.

Check that your hosting or your developer has applied the October patch. If nobody can tell you when it was applied, that is your answer.

Find out who is responsible for updates, in writing. Not “it updates itself”. Who checks, how often, and what happens when an update breaks a page.

Turn on two factor authentication for your hosting, your registrar and your site admin. It is the single highest return thing you can do in ten minutes.

If you do all three and the answers are fine, your site is fine. Plenty of them are. The problem is rarely the platform on its own, it is a platform nobody is looking after.

We are in Canowindra, and we build sites for businesses who would rather not think about any of this. If you are not sure who is patching yours, that is worth finding out this week.