Keeping a serverless site secure: what we actually check

When we compared WordPress and serverless honestly, one line mattered more than the rest: on serverless, security becomes your job, not a plugin's. A smaller attack surface is only safer if someone is still watching it. This post is that job written down. It is the actual checklist we run on our own site and every site we manage, not a theoretical best-practice list.

The shape of the risk

A serverless site has no always-on server to patch, no database listening on a port, and no admin login bolted to the front of it. Most of the classic ways websites get broken into simply are not there. What remains is a shorter list, and it is worth naming honestly:

• The few small functions that do run, like a contact form or a chatbot, and the secrets they hold.
• The DNS and domain settings that everything else trusts.
• The handful of dependencies in the build.
• The accounts of the people who can change any of the above.

None of that patches itself. So we check it, on a schedule, with the results written down.

The monthly hygiene check

Every site we manage goes through an automated check each month. It runs from a clean environment, probes the live site exactly as an outsider would, and opens a tracked issue the moment anything drifts from green. It covers:

• TLS and certificates. The certificate is valid, not close to expiry, and plain HTTP redirects straight to HTTPS. We also set HSTS at the edge, so returning browsers refuse to speak anything but HTTPS at all.
• Security headers on every response. X-Content-Type-Options, Referrer-Policy, X-Frame-Options and a Permissions-Policy that switches off browser features the site never uses. Small headers, big habits: they close off clickjacking, content sniffing and quiet data leakage.
• Technology disclosure. The site should not volunteer what it is built with. Version numbers and framework fingerprints in headers are free reconnaissance for an attacker, so we check none have crept in.
• Exposed paths. A probe of the usual suspects, the admin routes, config files and backup paths that scanners try first, confirming they return nothing useful.

This is hygiene, not a penetration test, and we are careful not to confuse the two. The monthly check catches drift. Deeper testing is a separate, periodic, human job.

Built in on day one

The checklist stays short because most of the security work happens before launch, in how the site is put together:

• Secrets live server-side only. API keys and system prompts sit in the platform's environment, never in the browser, never in the repository.
• Anything private fails closed. Admin areas sit behind identity-based access with the check enforced in the code itself. If the verification cannot complete, the answer is no.
• Public endpoints assume abuse. Forms and chat endpoints get rate limiting, same-origin checks and honeypots, so bots burn out before they cost anything.
• Webhooks prove who they are. Payment notifications are signature-verified before a single database write happens.
• Comparisons are timing-safe and tokens are unguessable. Boring cryptographic hygiene, done once, correctly, in one place.

The dependency question

A typical WordPress site carries a core application, a theme and a stack of plugins, each needing updates on someone else's timetable. Our builds are deliberately close to zero-dependency: plain files, a small build script, and only the libraries a feature genuinely cannot exist without. Fewer moving parts means the monthly question "is everything current?" takes minutes rather than a maintenance window. But the question still gets asked. A small surface that nobody reviews is just a small blind spot.

What still needs a human

Automation watches for drift. It does not think like an attacker, and it does not read context. So a human still:

• Runs a deeper security pass periodically, trying to break the forms, the auth and the assumptions, not just scan the headers.
• Reads the reports rather than filing them, because a new warning is only useful if someone acts on it that week.
• Reviews access: who can deploy, who can touch DNS, and whether every one of those accounts still needs to exist and has two-factor authentication switched on.

That standing vigilance is exactly what our support and care plans exist to provide. It is the difference between "we built it securely once" and "it is still secure this month", and only one of those statements ages well.

Not sure when your site last had any of this checked? Book a discovery call and we will tell you honestly where it stands, including the parts that are already fine.