Focus on where untrusted input is rendered and what runtime interprets it. If the browser and front-end framework evaluate the expression, you are looking at client-side template injection. If a back-end templating engine processes the input before response generation, the risk is server-side template injection. The distinction matters because the exploit path and impact are different.
Where the expression is interpreted, not just where it is stored, decides the testing path
The practical test is to trace the data flow to the first runtime that evaluates the payload as template syntax. Client-side template injection is a browser and front-end concern because the expression is executed in the user’s session context after the page loads. Server-side template injection is a response-generation concern because the payload is evaluated before the HTML ever reaches the browser. That difference changes what evidence you collect, what payload behaviour you expect, and how you interpret a failure.
For security teams, the mistake is often treating any reflected template marker as proof of server-side impact, or assuming that a browser-visible expression cannot have upstream implications. The correct view is that render location, runtime, and trust boundary all need to line up before you classify the issue. When they do not, teams can waste time testing the wrong tier, miss the real execution context, or underestimate whether the flaw affects only a single client session or a shared application path. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control lens for separating input handling, execution boundaries, and protective validation. In practice, many security teams identify the wrong injection path only after they have already tuned payloads for the wrong runtime.
Follow the render chain from input source to execution context
Testing starts with a simple question: which component transforms the input into executable template syntax? If the front end receives a value and the browser evaluates it through Angular, React-based interpolation, Vue, or another client-side templating mechanism, then the test should concentrate on client-side behaviour. You are looking for expression evaluation in the DOM, not just reflected text. If the application sends user-controlled input into a server template engine such as a back-end view layer, then the test should focus on server-side evaluation before the response is returned.
- Identify the first interpreter that treats the payload as syntax rather than content.
- Check whether evaluation happens after page load in the browser or before response delivery on the server.
- Observe whether the payload changes page state locally, or causes pre-render substitution in the returned HTML.
- Confirm whether the same input reaches multiple rendering paths, because mixed pipelines can create both conditions.
In practice, the safest way to classify the issue is to map the full path: input entry, transport, template rendering, and final execution. A payload that is harmless in raw response text may become dangerous once a client framework binds it into a component, while a payload that looks browser-only may still be evaluated upstream if server-side escaping is weak or the template engine is permissive. The testing objective is not to prove that something renders oddly, but to prove where the interpreter sits in the chain and whether the input reaches it unsafely.
That distinction also changes what success looks like. Client-side paths often produce visible DOM mutation, script-like evaluation within a component context, or a change that appears only in the browser after hydration. Server-side paths tend to affect the generated response itself, which can expose broader impact because the server has already processed the content before any user sees it. The guidance breaks down when applications use hybrid rendering, where the same value may be partially rendered on the server and then reinterpreted in the browser.
Hybrid rendering, sanitisation gaps, and misleading proof points
Tighter rendering controls often reduce exposure but increase testing complexity, so teams have to balance precision against the possibility of false classification. The hardest cases are not pure client-only or server-only flows, but applications that server-render a shell and then hand control to a front-end framework that reuses the same data. In those cases, a single payload can appear in both stages, and the first visible effect is not always the most important one.
One common edge case is output encoding that changes between layers. A value may be escaped by the server, then decoded or reinterpreted by client-side logic, which creates a client-side test path even though the raw response looked safe. The reverse can also happen when a back-end engine inserts untrusted data into a template block before the browser ever receives it. That is why the visible symptom is only a clue, not the final classification.
Guidance versus consensus: there is broad agreement that the interpreter boundary is the deciding factor, but teams differ on how much evidence is enough to call a path definitively server-side or client-side. NHI Management Group recommends treating the result as confirmed only when you can show both the evaluation context and the trust boundary, not merely the presence of template-like output. For mixed applications, test both stages separately rather than assuming one result rules out the other.
Where this breaks down most often is in modern single-page applications with server-side rendering, hydration, and delayed component binding, because the same payload may pass through more than one interpreter before the final user-visible effect appears.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 16 — Application Software Security | Template injection is an application-layer input handling and execution boundary issue. |
| Recommendation — Review application render paths and validate untrusted input before it reaches a template interpreter. | ||
| NIST CSF 2.0 | PR.DS — Data Security | The question turns on protecting data as it moves into rendering contexts. |
| Recommendation — Protect data flows into templates and preserve trust boundaries between input and execution. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Template injection exploits interpreter-like execution of attacker-controlled syntax. |
| Recommendation — Map template execution evidence to interpreter abuse and test the relevant execution path. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Secrets and Credential Exposure | Template injection can expose secrets when rendering paths leak sensitive values into output. |
| Recommendation — Audit rendered templates for secret leakage and remove sensitive values from unsafe render paths. | ||
Practitioner Guidance
What to prioritise: Establish the render boundary before expanding payload variants. If you cannot say which runtime interprets the expression first, the test is still exploratory rather than conclusive.
What to verify: Verify whether the payload is evaluated in the browser, the back-end template engine, or both. Also verify whether a later layer simply displays the result of an earlier interpretation, because that can mislead triage.
Decision rule: If the expression only becomes active after DOM binding, client-side testing should be primary. If the response body is already altered by template logic before it leaves the server, server-side testing is primary. If both occur, treat it as a layered issue and assess each execution point independently.
Common mistake: Treating reflected content as equivalent to execution. A string that appears in the page is not evidence of template evaluation until the runtime context is demonstrated.
Practitioner takeaway: The best classification comes from interpreter order, not from where the string is easiest to see, and mixed rendering should always be treated as a separate testing problem rather than a shortcut to one side.
Related resources from NHI Mgmt Group
- Why do server-side template injection bugs create broader risk than XSS?
- What breaks when client-side template injection is left uncontained?
- How should security teams prevent server-side template injection in CI/CD-driven applications?
- What is the difference between untrusted user markup and server-side template injection?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
