Based on insights from SUGCON Europe 2026
When teams move to Sitecore AI with Next.js on a Frontend-as-a-Service (FEaaS) host, they expect security to get simpler. Managed infrastructure, modern frameworks, less to worry about.
What actually happens is that security doesn't reduce. It disperses.
Instead of one platform to harden, you now have a rendering host, APIs, build pipelines, third-party scripts, and client-side bundles, all crossing trust boundaries. Each piece is individually defensible. The gaps are in how they connect.
We reviewed recent SitecoreAI deployments. Modern stacks, current best practices, that would pass many delivery checklists. In one example a solution scored a D on securityheaders.com. One security header out of six was present. The CSP allowed scripts from any domain including injected inline scripts. The site was live, serving customers.
Figure 1: A production deployed site, with common security misconfiguration
Nothing was broken. Everything was working. But the browser had almost no constraints on what it could load or execute.
That gap between "working" and "secure" is where many headless implementations sit right now.
This is the first in a series of posts that breaks down the controls that matter most in production headless Sitecore environments, with practical guidance you can apply immediately.
Headless Changes where Security Lives
In traditional Sitecore XP/XM, security was concentrated. You hardened CM/CD, locked down infrastructure, and controlled access at the network level. Most risk sat inside a well-defined perimeter.
Headless removes that perimeter. Rendering moves to the edge. Content is delivered via APIs. Builds happen in pipelines you don't fully control. Third-party services run directly in the browser.
Each boundary is a trust decision: between the frontend and APIs, between build and runtime, between environments, between your code and external dependencies. Most teams don't explicitly map those boundaries, so misconfigurations accumulate quietly.
The Data Makes More Sense in This Context
Industry reports point to misconfiguration, credential theft, and supply chain risk as dominant causes of breaches. Those findings are often treated as generic trends. In headless architectures, they’re structural.
Security Misconfiguration is now OWASP #2, up from #5. 100% of applications tested had some form of it (OWASP Top 10:2025). Headless multiplies the configuration surface because you're no longer managing one system, you're managing many, each with its own defaults and deployment model.
15.1 million secrets were detected in public GitHub commits in 2025, up 34% year on year (GitGuardian State of Secrets Sprawl 2026). In headless, credentials are no longer confined to servers. They exist in environment variables, build pipelines, and sometimes in client-side bundles, increasing the leak vectors.
Software Supply Chain Failures entered the OWASP Top 10 at #3 (OWASP Top 10:2025). Supply chain risk has become a primary concern because your application is now a composition of dependencies. In modern headless, a typical frontend build pulls in hundreds of packages, most of which you haven't reviewed directly. You are implicitly trusting a large, shifting dependency graph.
88% of web application breaches involved stolen credentials (Verizon DBIR 2025). When breaches happen, they overwhelmingly come down to credentials. In modern headless, more APIs and more services mean more tokens, more keys, and more opportunities for misuse. The architecture itself increases the attack surface.
Why These Gaps Persist
These gaps persist because nobody owns the full picture. In a monolith, infrastructure teams managed headers and transport. In headless, the rendering host is owned by frontend developers, APIs by backend teams or vendors, and platform behavior by the hosting provider. No single group has end-to-end responsibility for what the browser sees. Controls that were correct at launch degrade through framework updates, deployment changes, and environment drift. Security tooling exists but runs out of band, so findings get logged, deferred, and eventually become the baseline.
The Controls That Actually Make a Difference
There's no shortage of security guidance. These four areas aren't the only ones that matter, but across the Sitecore AI implementations we see, they are the ones that most consistently separate a well-secured platform from an exposed one. They're also the ones teams get wrong most often, even on otherwise well-built systems. We'll cover each of these in detail in this series:
1. Security headers and Content Security Policy. These define what the browser is allowed to load and execute. When they're missing or misconfigured, you've lost control of the client.
2. Secrets and token management. Credentials belong in vaults, not in repos, build logs, or client-side bundles. In distributed systems, that boundary is easy to cross without realizing it.
3. WAF configuration. Default OWASP rulesets break CMS traffic. Without tuning, teams either disable rules too broadly or never turn blocking on.
4. Continuous security testing in your pipeline. The difference between having a scanning tool and having it gate a release is where vulnerabilities live.
These are not advanced controls. They are foundational. The problem is that they are consistently implemented incorrectly.
What Comes Next
The next post covers Security headers and CSP, the area where most teams believe they're covered and where the largest gaps typically exist.
