Security for static websites: smaller attack surface, not zero
A static site removes the database, admin panel and plugins. What is left to protect, and the short list that keeps it safe.
The short answer
A static website is built once and served as finished files from a network. There is no database to inject, no admin login on the public site to brute-force, and no plugins executing on a server when a visitor arrives. That removes most of the ways business websites get compromised, and it is one of the main reasons we build this way. It does not remove all of them. What remains is the ring around the site: the accounts, the build and its dependencies, the functions that handle forms, the scripts loaded from third parties, DNS and the headers that protect visitors. Smaller surface, still a surface, and each part needs an owner.
What disappears and what remains
| Traditional site risk | On a static site |
|---|---|
| SQL injection through the database | Gone; there is no database behind the pages |
| Brute force on the public admin login | Gone; there is no public admin |
| Vulnerable server-side plugins and themes | Gone; nothing executes on the server per visit |
| File upload to the web root | Gone for the pages; functions handle uploads separately |
| Compromised platform or repository account | Remains: the highest-value target now |
| Malicious or vulnerable build dependency | Remains: what the site is built from |
| Bugs in form and API functions | Remains: the dynamic edges |
| Third-party scripts on the page | Remains: same risk as any site |
| DNS and domain account | Remains: controls everything |
| Missing security headers | Remains: visitor protection is configured, not automatic |
The short list that keeps it safe
- Two-factor on every account: repository host, platform, registrar, DNS, content system, email. The accounts are now the front door.
- Dependency updates on a schedule, with automated advisories and a lock file, so the build is made from known components.
- Secrets only in platform configuration, never in the front end; the built site is public.
- Functions treated as real code: validation, rate limits, least-privilege keys, logging.
- Third-party scripts kept minimal and, where used, pinned and integrity-checked.
- A content security policy and the other headers, set at the platform or network layer.
- A filtering layer in front for bot and attack traffic, and DNS locked at the registrar.
- Monitoring: uptime, function errors, unexpected deploys, domain changes.
What still goes wrong on static sites
A dependency with a vulnerability pulled into the build. A form function that trusted its input. A marketing tag added to every page from a service that was later compromised. A platform account with a password from a breach and no second factor. A DNS record left pointing at a service that was cancelled, later claimed by someone else. None of these is exotic; all of them are on the list above.
What this means for you
A static site gives you a much smaller and calmer security picture than a traditional one, and it is worth choosing for that alone. Then treat the remaining ring seriously: protect the accounts with two-factor, keep dependencies current, keep secrets out of the front end, be sparing with third-party scripts, set the headers, filter traffic and monitor. That short list, kept up, is what “secure by design” looks like in practice.
Frequently asked questions
Can a static site be hacked at all?
The published pages are files on a network; there is no server-side code to exploit on them. What can be compromised is everything around them: the repository or platform account through a stolen password, the build through a malicious dependency, a form function through a bug, or a visitor through a compromised third-party script. Smaller surface, real surface.
Do we still need security headers on a static site?
Yes. Headers protect visitors in the browser: against injected scripts, framing, content-type tricks and insecure connections. They are set at the platform or network layer and apply regardless of how the pages were made. A static site with a strict content security policy is one of the safest configurations available.
What about the content system editors use?
If content is edited through a hosted interface, that interface is an account to protect: two-factor, roles, access reviews. It is not exposed on your domain and does not run on your server, which is the improvement over a traditional admin panel, but the login still matters.