A static site's security surface is mostly someone else's

There is no database behind this site, no session, no request handler, and no runtime dependency install. A long list of familiar problems does not apply: injection into a query, a deserialisation bug in a request body, an authorisation check on the wrong branch.

What is left is worth naming, because "it's just static files" is where people stop thinking about it.

The build is the privileged step

Everything that has credentials happens at build time. Anything interpolated into a page during next build is in the output permanently, and any NEXT_PUBLIC_ variable is inlined into JavaScript that ships to every visitor. A secret in one of those is not hidden by obscurity — it is published, then cached at the edge.

So the rule here is blunt: if it must stay private, it cannot participate in this build, because there is no runtime to hold it instead.

The bucket is the application

With a private origin and an access control policy, the interesting failures are configuration ones. A bucket policy scoped too broadly, an error response left unmapped so every bad URL returns a bare 403, a stale object that the last deploy failed to prune while the HTML that referenced it was replaced.

None of those are code defects, which is why they survive code review.

Third parties are the actual attack surface

Every embedded script is a dependency that can change after you deploy. This site posts its forms to one external endpoint and embeds nothing else — no tag manager, no chat widget, no font CDN. That is not austerity; it is the only version of "we know what runs on this page" that stays true next week.

What we still owe

A content security policy, delivered as a response header from the distribution rather than a meta tag, and subresource integrity on anything we ever do embed. Both are edge configuration, and neither is in the repository yet.