Headless and Custom Website Security: The Risk Moves to Your Supply Chain

A headless or custom build, typically Next.js, Nuxt or Astro deployed to a platform like Vercel or Netlify, changes the shape of the risk rather than reducing it. There is no public admin login to brute force and no CMS to leave unpatched. In exchange, you own a dependency tree, a build pipeline, a set of environment variables and every API route you wrote.

This is a better trade only if you are equipped to manage those things. Teams that go headless for performance reasons and inherit the security obligations by accident are the ones that get caught.

Dependencies are the largest surface

A typical JavaScript application pulls in hundreds to thousands of transitive packages. You have read almost none of them, and any one of them runs with the privileges of your build or your server.

Three failure modes matter. A package with a known vulnerability that nobody updated, which is the common and boring case. A maintainer account compromise leading to a malicious release, which has happened repeatedly to widely used packages. And dependency confusion, where a build pulls a public package that shadows an internal one.

The controls are well understood and frequently skipped: run automated dependency auditing in CI and fail the build on high-severity findings, pin versions with a committed lockfile, keep the dependency count down as a deliberate policy, and be conscious of packages with a single maintainer and heavy install counts. See the plugin and app supply chain, which covers the same problem across platforms.

Secrets, and the ones that are not secret

The most common serious mistake in this stack is exposing a secret to the browser. Framework conventions decide what ships to the client, and a variable prefixed to be publicly readable will be in the bundle for anyone to find. API keys, database URLs and service tokens placed there are effectively published.

Audit which environment variables are client-exposed and confirm that every one of them is genuinely safe to publish. Keep real secrets server-side, rotate them when contractors leave, and never commit a .env file. Scanning your own repository history for committed credentials is worth doing once, because a secret that was committed and later removed is still in the history.

API routes are your application

Serverless functions and API routes are the part of a headless site that is genuinely yours to secure, and they are frequently written with less scrutiny than the same logic would receive in a traditional back end.

The recurring issues are authorisation checks that verify a user is logged in but not that they are allowed to touch the record in question, routes that accept a URL and fetch it server-side, missing rate limits on anything that sends email or costs money, and over-permissive CORS. None is exotic. All appear regularly in production.

Treat every route that mutates data or reads someone else's data as requiring an explicit authorisation check, and write a test for it.

The build pipeline is production

Your CI system holds credentials to deploy your site. Anyone who can modify the pipeline, or a compromised action or plugin used within it, can inject code into your build. This is precisely how supply chain attacks reach static sites that appear to have no attack surface at all.

Restrict who can change workflow files, pin third-party actions to a specific commit rather than a moving tag, scope deploy credentials narrowly, and require review on changes to the pipeline itself.

The headless CMS still has an admin panel

Going headless does not remove the CMS, it moves it. Whether that is Contentful, Sanity, Strapi or a headless BigCommerce, there is still a login, still an API token, and still a set of users with permissions. Everything in access control and 2FA applies to it, and a self-hosted headless CMS carries the same patching obligation as any self-hosted software.

What headless genuinely gives you

Statically generated pages served from a CDN have no server-side code executing per request, which removes a whole class of attack against the public site. That is a real benefit and it is why the architecture is attractive. Just be clear that the risk moved rather than disappeared, and that its new home requires engineering discipline rather than administrative diligence.

For how this compares with platforms where the vendor owns more of the stack, see website security by platform.