Edge Side Includes, or ESI, is a markup language for assembling web pages from cached fragments at the edge or in a proxy. It lets servers or CDNs combine reusable pieces such as headers, footers, or personalised blocks at request time, reducing origin load while keeping fragment-level caching and inclusion control.
How ESI Works in a Caching Architecture
Edge Side Includes sits between full-page rendering and pure static delivery. Instead of forcing a cache or CDN to treat every page as one opaque object, ESI lets the edge assemble a response from smaller fragments that can be cached, refreshed, and personalised on different schedules.
This is useful when some parts of a page are stable, such as navigation or editorial content, while other parts change more often, such as account-specific banners or regional notices. The architectural value is not just speed, it is finer control over what is cached, what is revalidated, and what must still come from origin.
Why ESI Exists
ESI emerged to solve a common web delivery problem: one origin can be too expensive or too slow to generate every page variant, but a fully static cache can be too blunt for personalised or rapidly changing content. Fragment assembly at the edge gives teams a middle path.
That design reduces origin load and can improve latency because the edge only fetches the fragments that need freshness. It also supports reuse, since the same header, footer, product tile, or alert block can be shared across many pages without rebuilding the whole page each time.
Operational Benefits and Design Trade-offs
ESI works best when teams understand fragment boundaries. The more clearly a page is decomposed into cacheable and dynamic pieces, the easier it is to preserve performance without accidentally serving stale or inappropriate content.
There is a trade-off, however: fragment assembly adds orchestration complexity. Cache policy, fragment validity, and edge behaviour must stay aligned, otherwise the page can become inconsistent, with some blocks fresh and others stale. A well-designed ESI implementation also needs to preserve origin intent, because fragment inclusion is still an application-layer decision rather than a simple static asset fetch.
Security Considerations for Fragment Inclusion
Because ESI changes how content is composed, the security model must account for each fragment as a separate trust boundary. If an attacker can influence an included fragment, poison cached content, or abuse inclusion rules, the edge may assemble a response that exposes data, misroutes users, or mixes content across contexts.
For this reason, teams should treat fragment sources, cache keys, and inclusion rules as security-relevant configuration. The technique is often discussed alongside web cache poisoning, request smuggling, and server-side include style abuse, because the risk comes from how intermediate systems interpret and combine content, not just from the origin application itself.
Risk and Threat Considerations
ESI introduces risk when edge composition is allowed to combine content from different trust levels without strong validation. The main exposure is incorrect fragment selection, cache poisoning, or unintended disclosure through personalised blocks that were cached or reused too broadly.
Failure mechanism: If fragment identity, cache scope, or inclusion inputs are manipulated, the edge can serve the wrong content to the wrong user or preserve malicious content long enough to affect many responses.
Impact: This can create cross-user data exposure, defacement, session-adjacent leakage, or persistent delivery of attacker-controlled markup until caches are cleared and the composition path is corrected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | ESI depends on secure cache and edge configuration for fragment assembly. |
| V15 — Secure Coding and Architecture | ESI is an application architecture pattern that changes how content is composed and trusted. | |
| Recommendation — Validate edge and cache configuration to prevent unsafe fragment inclusion and cache misuse. Design fragment boundaries so dynamic and public content are separated by trust level. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | ESI affects application delivery logic, caching behaviour, and inclusion controls. |
| Recommendation — Review application delivery paths for fragment injection, cache poisoning, and unsafe inclusion. | ||
| NIST SP 800-53 Rev 5 | SC-5 — Denial of Service Protection | ESI is used to reduce origin load and protect delivery capacity through caching. |
| Recommendation — Use edge caching and fragment reuse to reduce origin load and preserve service availability. | ||
Practitioner Guidance
What to watch for: ESI should be used only where fragment-level caching is genuinely needed and where the inclusion path is easy to reason about. If a page mixes public and user-specific material, teams should be explicit about which fragments are safe to cache broadly and which must remain tightly scoped.
Governance implication: The security owner for ESI needs to align application, CDN, and cache configuration so inclusion rules, cache invalidation, and trust boundaries are reviewed together rather than as isolated settings.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org