Any workflow in which user-controlled or externally sourced template content is processed by a server-side engine. This pattern is high risk when the renderer has access to commands, files, or secrets, because template syntax can become a vehicle for crossing from data into execution.
Expanded Definition
Untrusted template rendering occurs when a server-side template engine processes content that originated from a user, partner, tenant, or other external source without strong isolation or sanitisation. In NHI and application security work, the risk is not the template concept itself, but the possibility that template syntax can reach file access, command execution, or secret retrieval paths.
Definitions vary across vendors, because some tools focus only on server-side template injection while others also include unsafe rendering of email, document, chat, or workflow templates. The practical boundary is whether the renderer can interpret attacker-influenced directives instead of treating the input as inert data. That distinction matters under NIST Cybersecurity Framework 2.0, where safe processing of externally sourced content depends on controlling exposure, privileges, and runtime paths.
Untrusted templates become especially dangerous when they are rendered in automation that can reach service credentials, configuration files, or internal APIs. The most common misapplication is treating third-party template content as “just formatting,” which occurs when developers allow direct rendering in a privileged backend process.
Examples and Use Cases
Implementing template rendering safely often introduces workflow constraints, requiring organisations to weigh flexibility for dynamic content against the cost of sandboxing, validation, and reduced runtime privileges.
- A customer success portal lets tenants upload notification templates, but the service strips execution directives and renders them in a restricted sandbox before sending emails.
- An internal job system uses a shared report template that merges data from APIs; the renderer is isolated so the template cannot access environment variables or secrets.
- A CI/CD helper generates deployment manifests from user-supplied variables, following the principles documented in the Ultimate Guide to NHIs when secrets and service identities must not be exposed to template logic.
- A SaaS platform supports branded invoice templates, but only a safe subset of placeholders is allowed and the template engine cannot call shell commands or read local files.
- A help desk workflow ingests partner-authored message templates, and the system validates them against a fixed schema before rendering to prevent arbitrary expression evaluation.
Safe handling patterns align with guidance from the NIST Cybersecurity Framework 2.0, especially when user-controlled content moves through privileged automation.
Why It Matters in NHI Security
Untrusted template rendering is an NHI issue because the renderer often runs as a service account, automation bot, or application identity with access to tokens, certificates, and internal systems. If a template can escape its intended data-only role, the result can be secret disclosure, lateral movement, or unauthorised actions performed under a legitimate machine identity.
This risk is amplified by the state of the environment: Ultimate Guide to NHIs reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage. When template engines sit near those weak points, a single rendering flaw can become a credential exposure event rather than a cosmetic bug.
Practitioners should therefore treat template rendering as an access-control problem, not only a coding style issue. That means limiting what the engine can read, constraining the identity it runs under, and separating untrusted content from privileged execution paths. Organisations typically encounter the operational impact only after a template-driven breach or secret leak, at which point untrusted template rendering becomes 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 Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Template engines can expose secrets and run with excessive machine identity privilege. |
| NIST CSF 2.0 | PR.AC-3 | Privileged rendering paths must enforce least privilege for application and service identities. |
| NIST CSF 2.0 | PR.DS-1 | Templates carrying attacker input can expose sensitive data if rendering is not controlled. |
Restrict template renderers from accessing secrets, files, or commands and review their service identity scope.
Related resources from NHI Mgmt Group
- How should security teams implement authentication in React Router apps with server-side rendering?
- What should teams do when an agentic browser must handle untrusted content?
- What breaks when a workflow engine can execute untrusted code inside the same environment that stores secrets?
- Role template
