A security flaw that occurs when attacker-controlled data reaches the view name used by a Spring MVC controller. Instead of selecting a fixed template, the application may resolve a dynamic value, which can lead to template traversal, expression evaluation, or remote code execution depending on how the view engine processes it.
How Spring view name resolution becomes dangerous
Spring MVC view resolution is normally a simple routing step, where a controller returns a logical view name and the framework selects the matching template. Spring View Name Manipulation becomes dangerous when that value is influenced by attacker-controlled input, because the framework may treat it as a path or expression instead of a fixed presentation choice.
The core security issue is not the view layer itself, but the loss of trust in the controller-to-view boundary. If the application lets a user steer the view name, the request can escape its intended template, reach unexpected resources, or activate template engine features that were never meant to process untrusted data.
That is why the same flaw can range from simple template traversal to full code execution, depending on the view technology, the Spring configuration, and whether expression evaluation is in play. The pattern is especially serious when controller logic appears harmless, because the dangerous behavior emerges after the controller has already accepted and passed along the attacker’s value.
Typical exploitation paths and impact
The most common abuse path is path manipulation, where an attacker supplies fragments such as traversal sequences or template prefixes that influence what file or resource is selected. In some stacks, the danger escalates when the view resolver or template engine interprets special syntax, allowing expression injection or access to server-side objects.
Because the flaw sits at the presentation boundary, impact depends on the downstream renderer. A restrictive resolver may only expose template confusion or unauthorized template selection, while a permissive or misconfigured engine can turn the same issue into sensitive file disclosure, data exposure, or remote code execution. That variability is what makes the vulnerability easy to underestimate and hard to triage from a single code snippet.
For this reason, security review should focus on whether the view name is constant, derived from trusted server-side state, or built from request parameters, redirects, or model values that can be influenced externally. When the answer is the last category, the application is often closer to exploitation than the code suggests.
Why this flaw is especially risky in Spring applications
Spring makes it straightforward to separate controller logic from presentation, but that same flexibility can hide dangerous assumptions about what is safe to concatenate into a view name. If developers treat the returned view string as ordinary display metadata, they may miss that it is actually a control point for template lookup and sometimes expression processing.
The risk also increases when applications mix redirects, forwards, template inheritance, or dynamic path building without a strict allowlist. Small changes in the resolver, the template engine, or deployment packaging can alter the attack surface enough that a value that was once only a routing issue becomes an execution issue.
In practice, this flaw often appears alongside other input-handling mistakes, but the distinctive feature is that the attacker is not just changing page content. They are influencing which server-side view resource is selected, and in the worst case, how that resource is interpreted.
Secure handling patterns for view selection
The safest model is to keep view names static and choose them from server-side logic that cannot be rewritten by request data. Where dynamic behavior is genuinely required, the input should be reduced to a tightly bounded choice set and mapped to known template names rather than being passed through directly.
Teams should also review the view technology itself, because the same controller pattern can be harmless with one resolver and dangerous with another. A secure design for Spring view rendering is one where the framework only ever receives trusted presentation identifiers, not user-supplied fragments that can influence lookup paths or expression parsing.
When this discipline is in place, the controller can still support flexible UX flows without turning the template layer into an unintended attack surface.
Risk and Threat Considerations
This flaw can expose an application to unauthorized template access, sensitive file disclosure, and in some configurations, server-side expression execution. The practical risk is that a seemingly low-impact input field becomes a control channel into the view resolver, where attacker influence is transformed into server-side behavior.
Failure mechanism: attacker-controlled data reaches a view name, the resolver or template engine interprets it as a path or expression, and the application loads or evaluates content outside the intended template set.
Impact: the attacker may force unexpected template selection, disclose internal resources, or escalate from view manipulation to code execution if the renderer evaluates injected expressions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK 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 | CIS 16 — Application Software Security | Dynamic view-name handling is an application security weakness that CIS 16 helps govern. |
| CIS 8 — Audit Log Management | View-name abuse can be detected through unusual routing and error patterns that logging should capture. | |
| Recommendation — Validate server-side view selection and reject untrusted input before it reaches template resolution. Log view-resolution failures and suspicious template-path inputs for investigation. | ||
| NIST CSF 2.0 | PR.DS — Data Security | The flaw can expose internal resources or sensitive server-side content through unintended template access. |
| PR.AC — Identity and Access Management, Authentication and Authorization | The issue becomes material when attacker input changes what server-side resource or action the application authorizes. | |
| DE.CM — Continuous Monitoring | Suspicious view-resolution errors and template traversal attempts are detectable operational signals. | |
| Recommendation — Protect server-side presentation data and prevent untrusted values from influencing template selection. Limit which server-side resources a request can influence and enforce allowlisted view choices. Monitor for abnormal view-resolution failures and template traversal indicators. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Manipulating a Spring view name is an application-layer exploitation path against a public-facing service. |
| Recommendation — Track suspicious request patterns that attempt to steer server-side template resolution. | ||
Practitioner Guidance
What to watch for: review any controller that returns a view name built from request parameters, model attributes, or redirect-related values. The key judgement is whether the returned string is a fixed server-side choice or a value an attacker can shape into a different template target.
Practitioner takeaway: if a view name is not constant, treat it as a security-sensitive control surface, not a presentation convenience.
Related resources from NHI Mgmt Group
- What are the signs that a Spring controller is vulnerable to view name manipulation?
- How should teams prevent view name injection in Spring MVC applications that use Thymeleaf?
- Why does user-controlled data in a Spring view name create a remote code execution risk?
- What is the difference between returning a view name and returning a response body in Spring?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
