A Content Delivery API is the read-only interface a headless CMS exposes to deliver content to websites, apps, and other front ends. In Umbraco, it becomes security-sensitive because it can apply access checks to the requested node but still expose referenced content if related objects are not governed the same way.
What Content Delivery APIs do
A Content Delivery API is the read-only layer that exposes published content from a headless CMS to websites, apps, and other front ends. Its core job is delivery, not editing, which makes response shape, filtering, and access scope central to how safely content can be consumed.
How access control affects content delivery
In practice, a Content Delivery API is often where content visibility becomes a security question rather than a publishing question. If the API can check access to the requested node but not to every referenced object, related items may leak through otherwise legitimate responses. That is why API authorisation must be understood at the object and relationship level, not only at the endpoint level. For API-specific failure modes, the OWASP API Security Top 10 is the most direct reference point.
What can go wrong with referenced content
The main failure pattern is partial enforcement. A user or application may be allowed to fetch one piece of content while embedded relations, linked assets, or nested fields are governed differently. That creates a familiar broken-object style problem in content delivery, where the visible resource is allowed but the surrounding graph is not consistently protected. If delivery logic is too permissive, content exposure can scale quickly because the API is designed for broad reuse across channels.
Related delivery flaws also appear when API responses return more data than the front end actually needs. Over-broad payloads, weak object checks, and unsafe expansion of nested references can all expose unpublished or restricted material. In that sense, the Content Delivery API is not just a transport layer, it is a control boundary for what content relationships are allowed to cross from the CMS into consumer applications.
Why this matters for headless CMS design
Headless architectures separate content authoring from presentation, which improves reuse but also increases the importance of content modelling, relationship governance, and response filtering. The API becomes the enforcement point for what is published, what is related, and what is safe to resolve in a given context. A design that assumes the primary node check is enough will usually be fragile once content models include reusable blocks, linked media, or shared entities.
That is why delivery-layer security should be treated as a property of the content model itself, not only the API implementation. The safest pattern is a consistent policy for nodes, references, and embedded objects so that the access decision follows the data wherever the API can traverse it.
Risk and Threat Considerations
Content delivery APIs can expose more than intended when an attacker, or even a normal consumer, can follow references into content that was not meant to be visible. The risk is not limited to outright compromise, it also includes inadvertent disclosure of drafts, restricted assets, or internal relationships that were supposed to stay hidden.
Failure mechanism: The API enforces access at the top-level content node but does not apply the same policy consistently to referenced objects, expanded fields, or linked assets, allowing a broader response than the original request justified.
Impact: Restricted content can leak into public channels, cached responses, or downstream applications, creating confidentiality loss and making access control failures harder to detect because the response still appears valid.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Content delivery APIs can expose unauthorized referenced objects through object-level access gaps. |
| API3 — Broken Object Property Level Authorization | Returned fields and embedded properties can reveal more content than the requester should see. | |
| API8 — Security Misconfiguration | API response shaping and access enforcement often fail through permissive configuration. | |
| Recommendation — Apply API1 controls to enforce object-level authorization on every returned content reference. Apply API3 checks to restrict sensitive properties and embedded content in API responses. Review API8 settings to prevent over-broad exposure from default or permissive response behaviour. | ||
Practitioner Guidance
What to watch for: Review the delivery response as a graph, not just a single record. If your CMS allows nested content, make sure the rules for published nodes, linked objects, and media references are aligned so the API cannot become a bypass for content governance.
Governance implication: Ownership of content access should include both the API and the content model. If different teams govern publishing, permissions, and front-end consumption separately, the join points between them are where exposure most often appears.
Related resources from NHI Mgmt Group
- How should security teams reduce exposure when a headless CMS delivery API bypasses page-level access controls on referenced content?
- Why does a content delivery API create more risk when public and protected content are mixed in the same site?
- What happens when Public Access content is reachable through referenced nodes in a delivery API?
- Why do AI agents make content delivery a governance issue?