A web application flaw where untrusted input is processed inside a template context that can alter page logic or rendering behaviour. The risk is not only script execution in the browser. It is also the chance that template evaluation becomes a stepping stone to broader application abuse.
Expanded Definition
Client-side template injection, often shortened to CSTI, occurs when untrusted data is inserted into a browser-side template engine in a way that changes how the page is rendered or executed. Unlike ordinary output encoding failures, CSTI is about the template parser itself interpreting attacker-controlled syntax, which can affect expressions, bindings, and sometimes downstream application state. The issue sits close to cross-site scripting, but the important distinction is that the vulnerable point is the template evaluation layer, not just a raw HTML sink. Guidance for this term is still evolving across frameworks, because each client-side templating system exposes different expression features and escaping rules. For security teams, the key question is whether user input can reach a template context without strict separation of data and code. NIST’s control baseline on application development and secure coding in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because CSTI is fundamentally a code-in-data boundary failure. The most common misapplication is treating CSTI as a simple input-validation problem, which occurs when teams sanitize text after it has already been compiled into a template expression.
Examples and Use Cases
Implementing client-side templating rigorously often introduces stricter data-handling constraints, requiring organisations to weigh rendering flexibility against a much smaller attack surface.
- A single-page application renders user profile fields through a browser template engine, and attacker-controlled placeholders alter conditional logic instead of appearing as plain text.
- A support portal previews ticket content using client-side bindings, and a crafted payload changes how the template resolves variables, exposing hidden interface elements or unsafe functions.
- An e-commerce site uses a front-end framework for live search suggestions, and untrusted query text is concatenated into a template expression rather than passed as escaped data.
- A rich text editor allows custom components, but its preview pane evaluates template syntax from stored content, creating persistent exposure across sessions.
- OWASP guidance on OWASP Top 10 helps teams place CSTI alongside broader injection classes, while OWASP Web Security Testing Guide supports verification of unsafe template rendering paths.
Why It Matters for Security Teams
CSTI matters because it can collapse the boundary between user-controlled content and executable template logic, which undermines both browser trust and application integrity. When teams misread it as only a front-end nuisance, they may miss the fact that template evaluation can expose data, alter workflow states, or become a launch point for broader compromise. That is especially important in modern web stacks where client rendering, API consumption, and identity-aware interfaces are tightly coupled. A weak template boundary can also undermine session handling, profile views, and admin consoles if privileged data is rendered through the same component model. The control implication is straightforward: code review, secure design, and test coverage need to treat template expression handling as a high-risk sink, not just a presentation concern. NIST’s secure development controls in NIST SP 800-53 Rev 5 Security and Privacy Controls support that discipline, while the OWASP Application Security Verification Standard is useful for testing that untrusted input never reaches executable template contexts. Organisations typically encounter the business impact only after a live payload alters a production page, at which point CSTI becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Protecting data in transit and use depends on preventing untrusted input from becoming executable template logic. |
| NIST SP 800-53 Rev 5 | SA-11 | Secure coding and validation testing address injection risks in client-side template processing. |
| OWASP Agentic AI Top 10 | Template injection patterns overlap with unsafe code generation and execution boundaries in web apps. |
Treat template contexts as data-flow protection points and block unsafe rendering paths during design and review.
