# Is a Headless CMS More Secure?

> The headless vendors had a quiet October while PHP servers burned. Before you credit the architecture, ask which of three separations did the work, and whether your platform has all three.

Analyst Editorial by DXP Principal Analyst Group · Published 2026-11-03 · Not updated
Source: https://www.dxpscorecard.com/editorials/is-a-headless-cms-more-secure

## The short answer

A headless CMS is more secure when three things are true: the editing system is separated from the public website, the content is served through a read-only API with scoped keys, and the vendor runs and patches the platform. Contentful, Contentstack, Kontent.ai, SitecoreAI and Adobe Experience Manager rate highest on security and compliance in our scorecards, with Hygraph close behind. Self-hosted headless such as Strapi gives you the first two and leaves the third, the server, to you.

## Key takeaways

- Headless is not a security control. Separation is. The three separations that matter are editor from visitor (no admin login on your public domain), content from presentation (a read-only delivery API with keys that cannot write), and your team from the runtime (a vendor who patches before you read the advisory).
- PHP2Shell on 21 October 2026 was a runtime flaw, not a CMS flaw. It hit every server where a public visitor could talk to PHP directly, which is every coupled PHP site. Contentful, Contentstack, Kontent.ai, Hygraph, Storyblok and Sanity run no PHP and told customers nothing was required of them.
- The front end is still yours. React2Shell in December 2025 was a remote code execution flaw rated 10 out of 10 in React Server Components, and a default Next.js application was vulnerable. A headless architecture moves the runtime risk from the CMS to the website your developers build, and someone still has to patch that.
- Self-hosted headless is a server with an API. Strapi, Directus and Payload CMS each shipped critical fixes in 2026 for flaws in their own code, and the people who had to install them were their customers. The same is true of Adobe Experience Manager 6.5 on your own infrastructure, which needed a manual update for three flaws rated 10 out of 10 in October 2026 while the cloud service was patched for you.
- Buy the attestation, not the label. The platforms that rate highest on security and compliance in our scorecards hold a SOC 2 Type II report with more than the security criterion in scope, an ISO 27001 certificate in their own name rather than their cloud provider's, a public disclosure process and a clean or well-handled vulnerability record. Two of the most popular headless products, Storyblok and Sanity, are missing one of those.

## Our analysts' take

The question arrived in our inbox several times in the week after 21 October 2026, usually from a marketing leader whose WordPress or Drupal agency had spent a bad Tuesday upgrading PHP. The PHP project had shipped an emergency release for two flaws, nicknamed PHP2Shell, that let an attacker run code on a server without logging in. Both were rated 9.2 out of 10, both lived in PHP's own memory handling, and Amazon later reported attempts against its honeypots from 17 October, four days before the fix existed. By 26 October the United States Cybersecurity and Infrastructure Security Agency had put both on its list of exploited vulnerabilities and given federal agencies until 29 October to patch. Zscaler counted more than a thousand exploitation attempts against seventy organizations in the first 48 hours from its decoys alone. If your website ran on PHP and a visitor could reach it, you were in scope. If your content lived in Contentful or Contentstack and your website was a static build on a content delivery network, you read about it the way you read about weather somewhere else.

That contrast is real, and it is why the question is worth answering carefully rather than cheering. A headless CMS stores content behind an API and leaves the website to a separate application, so the pitch writes itself: no PHP, no plugin directory, no admin login on your domain, nothing to patch. All of that was true in October. But none of it comes from the word headless. It comes from three separations that a headless architecture makes easy and does not guarantee: the editor from the visitor, the content from the presentation, and your team from the runtime. A self-hosted Strapi on a virtual machine has the first two and not the third. Adobe Experience Manager as a Cloud Service, which nobody calls headless, has all three for its customers and still shipped fixes for three flaws rated 10 out of 10 on 13 October 2026. Ten months before PHP2Shell, the React Server Components flaw known as React2Shell, also rated 10 out of 10, hit the exact front-end stack most headless sites are built on, and a default Next.js project was exploitable. The runtime did not go away. It moved.

So here is our position. Yes, a cloud-managed headless CMS is more secure than a coupled CMS that your own team runs, by a wide margin, and October proved it in the only way that counts. No, headless by itself is not more secure than a coupled platform that a vendor runs for you, and in the cases where the headless CMS is self-hosted or the front end is unmaintained it can be worse, because the people who bought it believed they had nothing left to patch. The rest of this editorial separates the three separations, shows where each platform in our scorecards actually stands on them, and names the ones that rate highest on security and compliance with the evidence that put them there.

## What to look for

1. **Where the admin login lives.** Open your website and try to find a login page. On a coupled CMS it is on your domain, usually at a guessable path, and it leads to the same runtime that serves visitors. On a cloud headless CMS the editing interface runs on the vendor's domain behind the vendor's SSO, and your public site has no login at all. That single fact removes the most attacked door on the web.
2. **Whether the public key can write.** Ask for the API token model. A delivery token that can only read published content, separate from a management token that can write, with scopes per space or environment and an expiry you set, means a leaked key in a front-end bundle exposes content and nothing more. One key that does everything, or a token that never expires, means the headless architecture has reintroduced the risk it was sold to remove.
3. **Who patches the runtime, and how fast.** In writing, and with a date. For a cloud platform the right answer in October 2026 was that nothing was required of the customer. For a self-hosted platform, headless or not, the answer is a person on your side, and the honest follow-up is how long they took the last time a critical fix shipped. Ask the same question about the front end: who upgraded React and Next.js in December 2025?
4. **Attestations in the vendor's own name.** A SOC 2 Type II report tells you an auditor watched the controls operate for a year; ISO 27001 tells you the security program is certified and re-audited. Insist that both name the platform, not the cloud it runs on. Every vendor on this page runs on AWS, Google Cloud or Azure, and the hosting provider's certificate is not theirs. Then read what the SOC 2 covers, because security-only is the minimum, not the norm.
5. **A vulnerability record you can read.** A public disclosure policy, a bug bounty or at least a security address, and a searchable advisory history. A clean record counts for more when it is verifiable (a search of the public advisory databases returning nothing) than when the vendor simply says so. A bad year handled well, with same-day fixes and clear advisories, is better than silence.

## The three separations that actually did the work in October

Headless architecture is credited with security it only enables. Each of the three separations below can exist without the other two, and a platform earns credit for the ones it actually has, not for the category it sells in.

- **Editor from visitor: separation of roles.** In a coupled CMS the editor and the anonymous visitor share one application, one database and one login page on the public domain, so an unauthenticated request can reach the code that also runs the admin. PHP2Shell needed nothing more than that. In a cloud headless CMS the editor works in the vendor's application on the vendor's domain, under SAML single sign-on and multi-factor authentication, and the visitor never touches it. Your public site is a build output or a rendering layer with no admin, no session store and no database. Roles are separated by architecture, not by a permission table that a plugin can bypass.
- **Content from presentation: API first.** API first means the content is reachable only through a defined, versioned interface, and the interface is split by intent. Contentful, Contentstack, Kontent.ai, Hygraph and Storyblok all separate a read-only delivery API from a management API, with distinct tokens, and most now scope and expire them: Contentful lets an organization cap the lifetime of personal access tokens, and Storyblok is forcing every unscoped token out of use by November 2026. The point is blast radius. A key that leaks from a build log can read what was already public, and nothing else. A coupled CMS has no such boundary; the same session that renders a page can change it.
- **Your team from the runtime: someone else patches.** This is the separation that decided October, and it has nothing to do with headless. Contentful, Contentstack, Kontent.ai, Hygraph, Sanity and Storyblok patch their own platforms with no customer action, and so do SitecoreAI and Adobe Experience Manager as a Cloud Service, which are suites with page builders. Adobe's 13 October release fixed 35 vulnerabilities including three rated 10 out of 10; cloud customers got them automatically, while organizations running Adobe Experience Manager 6.5 on their own servers had a PHP2Shell week of their own, one week early and in Java. The runtime you do not run is the runtime you do not have to patch, whatever the product is called.

## What headless does not fix, and what it quietly adds

A buyer who stops at the first section will conclude that the answer is yes and move on. The four cases below are where that conclusion gets organizations breached.

- **The front end is a runtime too.** A headless site is usually a Next.js, Nuxt, Astro or Remix application that your developers build and host on Vercel, Netlify, Cloudflare or your own cloud. On 3 December 2025 React2Shell, a remote code execution flaw rated 10 out of 10 in React Server Components, was disclosed with public exploit code within days, and a project created with the default Next.js tooling was vulnerable. The CMS vendors had nothing to patch; their customers did. If a static build is all you serve, the exposure is small. If you render on the server, you have exactly the problem PHP2Shell posed, in JavaScript, and the person who has to fix it is the developer who built the site, who may have moved on.
- **Self-hosted headless is a server with an API.** Strapi, Directus and Payload CMS are headless by every definition and run on infrastructure you control. Strapi's coordinated disclosure on 13 May 2026 covered five flaws, including a critical SQL injection in the Content-Type Builder and an unauthenticated route that exposed password reset tokens. Directus published a steady stream of 2026 advisories for upload authorization bypasses and file API path traversal. Payload CMS fixed a critical blind SQL injection in its database adapter in version 3.73.0. Each vendor fixed its flaw quickly. Each customer then had to deploy the fix, which is the job the headless pitch implied they no longer had. All three sell a cloud edition that takes the job back, and their SOC 2 attestations cover that edition, not your server.
- **The keys and the pipeline are the new perimeter.** Headless moves the risk from the server to the credentials: management tokens in continuous integration secrets, preview secrets in environment variables, webhook endpoints that trigger rebuilds, and an AI agent with a Model Context Protocol connection to the content. A token that can publish is a token that can deface, and it now lives in a build system rather than behind a login. Storyblok's scoped tokens, Contentful's token expiry and author filtering, Kontent.ai's separate delivery, preview and management keys and SitecoreAI's OAuth flow for its agent connectors are the vendors' answers. Whether your team uses them is yours.
- **Vendor-run is not the same as vendor-perfect.** Salesforce Experience Cloud holds the broadest certifications in our scorecards and still spent a year watching customer orgs leak data through misconfigured guest-user access, which no certificate prevents. Adobe Experience Manager carries a heavy run of critical fixes in 2026 even though the cloud service applies them for you. A vendor who patches for you removes the work; it does not remove the flaw's window, and the width of that window is what the vulnerability record tells you. Read it.

## Which platforms rate highest on security, and why

Our scorecards grade every platform on the same security evidence: authentication and authorization, the vulnerability record, who applies patches, SOC 2 and ISO certification in the vendor's own name, audit logging and data residency. The platforms below sit at the top on that evidence as of this editorial's date, with the gaps that keep others off the list. The scorecard links at the end of this page carry the current ratings.

- **Contentful: the reference headless posture.** SOC 2 Type II covering security, availability and confidentiality, ISO 27001 certified since 2019 and migrated to the 2022 revision, SAML single sign-on with organization-wide multi-factor authentication and up to five identity providers, and a public advisory record that shows one medium-severity issue in 2021 and nothing since. Token lifetimes can be capped by policy. This is the posture every other headless vendor is measured against.
- **Contentstack: enterprise controls, clean record.** SOC 2 Type II with four criteria in scope including privacy, ISO 27001 in Contentstack's own name, SAML single sign-on with up to five identity providers and SCIM provisioning, and no CVE ever assigned against a Contentstack product. Platform patching is announced and vendor-side, including Kubernetes lifecycle upgrades run without downtime in October 2026. The one gap is the absence of OpenID Connect; it is SAML or nothing.
- **Kontent.ai and Hygraph: the mid-market pair.** Kontent.ai holds SOC 2 Type II, ISO 27001, ISO 27017 and ISO 27018, and was the first CMS to certify its AI governance to ISO 42001; the trade-off is that single sign-on is an enterprise-plan feature. Hygraph has held SOC 2 Type II since 2023, renewed for another year in 2026, offers SAML and OpenID Connect on enterprise plans, and has no public advisories; its ISO 27001 claim rests on its hosting provider, which is the one line on its security page we would ask it to clarify.
- **SitecoreAI and Adobe Experience Manager: the suites that qualify.** Both are cloud-run, both hold SOC 2 Type II and ISO 27001 in their own names (Sitecore adds CSA STAR, Adobe adds ISO 27017 and 27018), both offer SAML and OpenID Connect with enforced multi-factor authentication, and both patch the cloud editions without customer action. Sitecore hardened its deserialization defaults in September 2026 before any disclosure forced it. Adobe's record is the weaker of the two, with repeated critical fixes through 2026, but the cloud service applies them. A buyer who wants the page builder and the personalization in one contract gives up nothing on security by choosing either over a headless product.
- **Storyblok and Sanity: popular, with one gap each.** Storyblok is ISO 27001 certified by TÜV Rheinland since March 2022, holds TISAX for automotive buyers, and led the market on scoped tokens in 2026, but it has no SOC 2 report of its own; the SOC 2 it cites belongs to AWS. Sanity holds a SOC 2 Type II that covers only the security criterion, and no ISO 27001 of its own; the ISO certificates on its security page are Google Cloud's. Both have clean public vulnerability records and vendor-managed patching, so a security team will likely approve them, but procurement in a regulated industry will ask for the missing document, and today neither can produce it.

## Platforms in this piece

- [Contentful](https://www.dxpscorecard.com/platform/contentful) (Markdown: https://www.dxpscorecard.com/platform/contentful.md)
- [Contentstack](https://www.dxpscorecard.com/platform/contentstack) (Markdown: https://www.dxpscorecard.com/platform/contentstack.md)
- [Kontent.ai](https://www.dxpscorecard.com/platform/kontent) (Markdown: https://www.dxpscorecard.com/platform/kontent.md)
- [Hygraph](https://www.dxpscorecard.com/platform/hygraph) (Markdown: https://www.dxpscorecard.com/platform/hygraph.md)
- [SitecoreAI](https://www.dxpscorecard.com/platform/sitecore-ai) (Markdown: https://www.dxpscorecard.com/platform/sitecore-ai.md)
- [Adobe Experience Manager](https://www.dxpscorecard.com/platform/aem) (Markdown: https://www.dxpscorecard.com/platform/aem.md)
- [Storyblok](https://www.dxpscorecard.com/platform/storyblok) (Markdown: https://www.dxpscorecard.com/platform/storyblok.md)
- [Sanity](https://www.dxpscorecard.com/platform/sanity) (Markdown: https://www.dxpscorecard.com/platform/sanity.md)
- [Strapi](https://www.dxpscorecard.com/platform/strapi) (Markdown: https://www.dxpscorecard.com/platform/strapi.md)
- [WordPress](https://www.dxpscorecard.com/platform/wordpress) (Markdown: https://www.dxpscorecard.com/platform/wordpress.md)

## Frequently asked questions

### Is a headless CMS more secure than a traditional CMS?

A cloud-managed headless CMS is more secure than a traditional CMS you host yourself, because the admin login, the database and the runtime leave your domain and the vendor patches them. It is not automatically more secure than a traditional or suite platform that a vendor runs for you, such as SitecoreAI or Adobe Experience Manager as a Cloud Service. What matters is who patches, where the login lives and whether the public API key can write.

### Did the PHP2Shell vulnerability affect headless CMS platforms?

Not the cloud ones. PHP2Shell, the pair of PHP flaws fixed on 21 October 2026, affected servers running PHP, which means WordPress, Drupal, Joomla, TYPO3, Craft CMS and Statamic installations plus any PHP front end. Contentful, Contentstack, Kontent.ai, Hygraph, Storyblok and Sanity run no PHP and required no customer action. A headless site with a PHP front end, or a self-hosted PHP headless CMS, was in scope like any other PHP server.

### Which headless CMS is the most secure?

On the evidence in our scorecards, Contentful and Contentstack lead: SOC 2 Type II with several criteria in scope, ISO 27001 in their own names, enterprise single sign-on and clean public vulnerability records. Kontent.ai and Hygraph follow closely. Storyblok lacks its own SOC 2 report and Sanity lacks ISO 27001, which matters in regulated procurement. Self-hosted Strapi, Directus and Payload CMS depend on how well you run the server.

### Does a headless CMS remove the need for security patching?

It moves it. The vendor patches the CMS, but your front end, usually a Next.js or similar application, is still software your team maintains. React2Shell in December 2025 was a remote code execution flaw rated 10 out of 10 in React Server Components, and default Next.js projects were vulnerable. Keep a named owner for front-end dependency updates, or serve a fully static build so there is little left to exploit.

### What security certifications should a CMS vendor have?

At minimum a current SOC 2 Type II report covering security, availability and confidentiality, and ISO 27001 certification, both in the vendor's own name rather than inherited from AWS, Google Cloud or Azure. Add ISO 27018 for personal data in the cloud, a HIPAA business associate agreement if you handle health data, and a published vulnerability disclosure policy. Ask to read the SOC 2 under NDA rather than accepting a badge on a website.

## About this editorial

A position the DXP Principal Analyst Group took on 2026-11-03. It is not updated; a changed view is published as a new editorial. The linked scorecards carry the current ratings for every platform named here. Scorecards and platform inclusion are unsponsored: no vendor pays to be named in an editorial or to change a rating.
