Your Website Has No Database to Hack

When someone visits a conventional CMS-driven site, the server does real work. It parses the request, runs application code, opens a connection to a database, executes queries built partly from what the visitor sent, loads whatever plugins are installed, lets each of them run their own code against the request, assembles a page, and returns it.

Every one of those steps is a place where a mistake becomes a vulnerability. And critically, most of that code was not written by the people who own the site, was not reviewed by them, and updates on a schedule they do not control. A plugin author's bad afternoon becomes a business's incident.

The scale is what makes it a numbers game rather than a targeting problem. Nobody is choosing your business. Automated scanners sweep enormous ranges of the internet asking every address the same short list of questions — is there an admin panel here, is there a known vulnerable plugin version, did someone leave a config file where I can read it. Being small is not protection. Being small mostly means nobody notices for longer.

Every Araptus Highlander site is compiled ahead of time. Content is written in files kept under version control, a build turns those files into finished HTML, and the finished HTML is what gets deployed. When a visitor arrives, the server hands them a document that was already written. It does not consult anything, run anything, or decide anything.

This is not a trick for simple sites. Search, forms, bookings, payments and dashboards all still work — they are just no longer capabilities of the website. They are separate, narrowly scoped services with their own authentication, their own rate limiting, and their own blast radius. A form endpoint that gets abused exposes what that one endpoint can reach. It does not expose the site, and there is no shared database sitting behind everything waiting to be dumped.

The security benefit is a side effect of an architecture chosen for other reasons — pages served as files from a CDN are also fast, and a site with no runtime cannot be slow because a plugin is slow. But the security benefit is the one owners feel, because it converts an ongoing vigilance problem into a structural fact. You cannot fail to patch a plugin you do not have.

Removing the attack surface has one downside: you stop being able to see who was trying. Scanners still arrive, but a static site answers every unknown path with the same blank 404 and nobody learns anything. So this site runs a small set of deliberate traps — fourteen paths that do not exist and never will, but which every automated scanner asks for anyway.

They are the usual shopping list: environment files, cloud credential files, a repository config file, a couple of PHP diagnostic endpoints, an admin panel or two, a framework debug route. Each one answers with a decoy 404 that presents as an ordinary PHP host, and reports the attempt over a signed channel to our firewall. The most-probed path across the whole set is the one that leaks a repository's remote URLs.

Getting the traps working at all took three failed approaches, and the failures are the genuinely useful part. Routing rules applied too late to matter, because the platform evaluates them after the framework's own catch-all has already answered. Splicing entries into the generated build output landed after the handler they were supposed to precede. Reordering them ahead of it, with each of the two available continuation flags, still failed to resolve a rewritten path onto a real function.

What worked was giving up on rewriting and registering the traps as ordinary routes the framework knows about, so the deployment adapter emits them itself. That also reached paths that file-based routing cannot express — a dotfile path like a repository config cannot be a filename in a pages directory, but it can be a URL pattern. Since that is the single most-probed path we see, it mattered.

It would be easy to end here claiming a static site cannot be attacked. That is not true, and the claim would be the tell that this is marketing rather than architecture.

Domain registrars and DNS remain a live target, and taking those gets an attacker everything regardless of how the site is built. Hosting and repository accounts need multi-factor authentication, because that is now where the keys are. The build pipeline runs code and needs treating like production. Third-party scripts dropped into a page for analytics or chat run in your visitors' browsers whatever the rest of the architecture looks like. And every service behind a form is its own system with its own risks.

What goes away is one specific category, and it happens to be the largest and most automated one: remote exploitation of a database-backed application that executes untrusted code on every public request. That is the category the internet-wide scanners are built for. Removing it does not make a business un-attackable. It makes the business stop being a target of opportunity, which for a company that is not being deliberately hunted is most of the actual risk.