How should teams prevent view name injection in Spring MVC applications that use Thymeleaf?

Treat any user-influenced view name, fragment, or implicit route-derived template as untrusted input. Use fixed view names, keep request data out of template resolution, and prefer ResponseBody or RestController when returning raw content. Review controller methods that concatenate path or fragment values, because Thymeleaf can interpret them as expressions before rendering and turn a simple routing mistake into remote code execution.

Where view name injection starts in Spring MVC

View name injection is a template resolution problem, not a general “bad input” problem. It appears when controller logic turns attacker-controlled data into a view name, fragment selector, or template path, and the view layer then interprets that string with expression semantics instead of treating it as inert text. In Spring MVC with Thymeleaf, that boundary is what turns routing convenience into code execution risk.

The safest mental model is simple: the controller should decide which template to render, while request data should only populate model attributes. If a request parameter, path segment, or derived route value influences the name of the view itself, you have crossed from rendering data into steering the renderer.

Common failure patterns include returning concatenated strings from controllers, using a path variable inside a redirect or forward target, and deriving fragment references from request input. Even when the code looks like a harmless shortcut, Thymeleaf can evaluate template expressions during resolution, so the issue is the trust boundary around the view name, not just the syntax used to build it.

How to harden Spring MVC and Thymeleaf controllers

Use fixed view names wherever possible, and keep all user input out of view resolution. A controller should map to a known template such as “home” or “error”, then pass request data through the model for display inside that template. If the endpoint is meant to return raw data rather than HTML, prefer OWASP Top 10-style application design discipline and use @ResponseBody or @RestController so the framework does not attempt template lookup at all.

Review any method that builds a return value from a path variable, query parameter, or fragment string. The highest-risk cases are concatenation and indirect routing, because they make it easy for a malicious value to escape the intended template name and become part of the rendering instruction. If the value has to influence presentation, constrain it to a small allowlist of known-safe variants and resolve that choice in code, not in a string expression.

Also be careful with fragments and template selectors. A fragment reference that seems harmless in ordinary use can become dangerous when it is assembled from request data, because the view resolver may interpret it before rendering. Treat fragment names, template paths, and redirect targets as configuration, not user content.

Risk and Threat Considerations

View name injection is dangerous because it can convert a routing or presentation bug into server-side expression evaluation. The practical concern is not only page tampering, but template engine abuse, unexpected file or fragment resolution, and in the worst case remote code execution when the crafted input reaches an expression-capable rendering path.

Failure mechanism: A controller passes untrusted input into view resolution, Thymeleaf evaluates that value during template lookup or fragment handling, and the attacker gains influence over what the server renders or executes.

Impact: Attackers can alter responses, reach unintended templates, disclose data, or trigger code execution in vulnerable configurations, which makes the flaw far more serious than a simple injection bug in the UI.

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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-02 — Secrets and Credential Exposure	View name injection can expose higher-impact server-side execution paths when untrusted input reaches template resolution.
	NHI-07 — Input Validation and Boundary Enforcement	The flaw begins when untrusted routing or fragment input crosses into the rendering boundary.
Recommendation — Keep request data out of template resolution and restrict controller return values to fixed, non-user-controlled view names. Validate and allowlist any user-influenced route, fragment, or template selector before it can affect rendering.
CIS Controls v8	CIS 16 — Application Software Security	Controller and view-resolution bugs are application-layer flaws that require secure coding and review controls.
Recommendation — Review controller code for string-built view names and remove any request-driven template selection paths.
OWASP Agentic AI Top 10	LLM-07 — Prompt Injection	Like prompt injection, view name injection abuses an untrusted string to steer a downstream interpreter.
	AGENT-03 — Tool Misuse and Unauthorized Action	The core lesson is that attacker-controlled input must not be allowed to trigger unintended server-side actions.
Recommendation — Treat any user-controlled selector as hostile input and prevent it from steering the interpreter. Constrain all externally influenced action selectors to fixed, allowlisted outcomes.
MITRE ATT&CK	T1202 — Indirect Command Execution	The attacker influences an interpreted execution path indirectly through a higher-level application mechanism.
Recommendation — Hunt for application paths where user input is transformed into executable instructions or interpreted selectors.

Practitioner Guidance

What to verify: Audit controller return values for any string assembly that includes request-derived data, especially path variables and fragment names. If the value is not a hardcoded view identifier or an explicit allowlisted choice, treat it as suspect.

Common mistake: Teams often secure model attributes but overlook the view name itself. That leaves a narrow but high-impact path where the presentation layer still interprets attacker influence before rendering.

Decision rule: If the endpoint’s purpose is to deliver JSON, text, or another non-template response, bypass view resolution entirely. If it must render HTML, keep the template fixed and let the data vary only inside the model.

Practitioner takeaway: The safe design is to make routing and template selection deterministic, because once user input can influence the resolver, the issue becomes an execution boundary problem rather than a formatting issue.