The JAMstack attack surface is everything an attacker can influence in a site made of JavaScript, APIs and prebuilt markup: the build pipeline and its packages, the CDN and DNS settings, the client-side code in the browser, and every API, function or service the pages call.
Definition in four parts
JAMstack describes sites built ahead of time into static files, served from a CDN, with dynamic behaviour added by browser JavaScript and by APIs. The security model changes in a useful way: fewer servers to patch, but more reliance on third parties and on the build.
Attack surface is the set of places where untrusted input or untrusted code can reach something you care about.
Putting those together gives a map with five zones.
| Zone | Example assets | Typical risk |
|---|---|---|
| Source and build | Repository, CI, generator plugins, lockfile | Malicious or vulnerable package runs with build credentials |
| Output files | Bundles, HTML, source maps | Vulnerable front-end library, leaked values compiled into the bundle |
| CDN and DNS | Custom domains, redirect rules, headers, cache | Takeover of an abandoned record, missing headers, cached private data |
| Browser runtime | Third-party scripts, embeds, tag managers | Third-party code runs with your page's privileges |
| APIs and functions | Form handlers, auth, search, payments | Weak authorization, over-permissive CORS, vulnerable dependencies |
What changes compared with a server-rendered app
Traditional apps concentrate risk in one runtime. A static architecture spreads it. That is not worse by default, but it makes inventory the first job. If you cannot list your functions, embeds and external APIs, you cannot say who owns the risk in each.
Two consequences follow.
- Trust decisions multiply. Each script tag, each SaaS API and each build plugin is a supplier.
- Server-side checks move. If a rule matters, such as who may read a page, it needs to be enforced where the content is actually served, in more than the browser.
How to map yours in an hour
- List every repository that contributes to the site, including the functions folder and any content repository.
- Export the dependency list from each lockfile and mark build-only versus shipped.
- Search the built output for external hostnames. Each one is a runtime dependency.
- List custom domains and subdomains and confirm each still points at something you control.
- List environment variables and mark which are compiled into the public bundle. Framework documentation states that variables with a public prefix are inlined into client JavaScript at build time. See the Next.js environment variables guide in Sources.
- Note which API keys exist, what each can do, and who can rotate it.
Try it yourself
The continuous monitoring demo shows how an inventory is rescanned after deploy. Watch for how a new advisory changes the status of something already shipped.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard provides SBOM generation, dependency scanning and asset discovery, so the map above can be built and kept current rather than drawn once. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is JAMstack a product?
No. It is an architecture style, so there is no single vendor or version to patch.
What is the first thing to inventory?
The external hostnames in your built output, because each one is code or data you do not control.
Sources
- Next.js documentation, environment variables: https://nextjs.org/docs/app/guides/environment-variables
Last reviewed: 19 October 2026.
