Elegant Redirect Solutions in Spring MVC: Avoiding URL Parameter Exposure

Problem Context and Challenges

When building RESTful Spring MVC applications, handling redirects after form submissions is a common yet often overlooked technical detail. Developers typically expect to add attributes via ModelMap in controller methods and retain this data after redirects without exposing it in plain text within URLs. However, Spring MVC's default behavior does the opposite: when using the redirect: prefix, all model attributes are automatically encoded as URL query parameters. This not only leads to excessively long and unreadable URLs but, more critically, may leak sensitive information or create security vulnerabilities.

Analysis of Default Behavior

Consider the following typical controller code snippet:

@RequestMapping(method = RequestMethod.POST)
public String processForm(ModelMap model) {
    model.addAttribute("notification", "Successfully did it!");
    return "redirect:/form";
}

After executing this redirect, the generated URL might resemble /form?notification=Successfully%20did%20it!. While this mechanism is straightforward, it is often unacceptable in real-world applications, especially when model attributes contain user data, business states, or temporary tokens.

Core Solution: Temporary Implementation Based on SPR-6464

According to records in the Spring issue tracker SPR-6464, the community offers a temporary solution for environments prior to Spring MVC 3.0.2. The core idea is to customize redirect logic by intervening in the model attribute exposure process through filters or view resolvers.

First, create a custom subclass of RedirectView, overriding its model handling logic:

public class SafeRedirectView extends RedirectView {
    @Override
    protected void exposeModelAsRequestAttributes(Map<String, Object> model, HttpServletRequest request) {
        // Empty implementation to prevent model attributes from being exposed as request attributes
    }
}

Then, configure a Spring MVC interceptor or filter to replace the default view resolution behavior before redirects:

public class RedirectAttributeFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException {
        // Detect redirect requests and apply custom views
        if (request.getAttribute(HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE) != null) {
            request.setAttribute(View.RESPONSE_STATUS_ATTRIBUTE, HttpStatus.SEE_OTHER);
            // Use SafeRedirectView to handle redirects
        }
        chain.doFilter(request, response);
    }
}

Finally, register this filter in the Spring configuration file:

<bean id="redirectAttributeFilter" class="com.example.RedirectAttributeFilter" />
<mvc:interceptors>
    <bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter" />
</mvc:interceptors>

Comparison of Alternative Approaches

Beyond the core solution, developers can choose other methods based on specific needs:

Approach 1: Using RedirectView with Disabled Model Exposure
Directly return a RedirectView instance and explicitly control exposure via setExposeModelAttributes(false):

@RequestMapping(method = RequestMethod.POST)
public View processForm() {
    RedirectView redirectView = new RedirectView("/form");
    redirectView.setExposeModelAttributes(false);
    return redirectView;
}

This method is straightforward but requires repetitive configuration at each redirect point and cannot directly transfer existing ModelMap data.

Approach 2: Passing Minimal State via Query Parameters
When only simple state flags (e.g., success/failure) need to be passed, encode data as URL parameters and receive them in the target controller via @RequestParam:

return "redirect:/form?success=true";
// In the target method
public String handleRedirect(@RequestParam(required = false) Boolean success, Model model) {
    if (Boolean.TRUE.equals(success)) {
        model.addAttribute("message", "Operation successful");
    }
    return "form";
}

This approach works for non-sensitive data but lacks flexibility and may result in verbose URLs.

Approach 3: Temporary Session Storage
For complex objects or collections, consider using HTTP sessions for temporary storage, clearing them after redirects:

@RequestMapping(method = RequestMethod.POST)
public String processForm(HttpSession session) {
    session.setAttribute("tempData", complexObject);
    return "redirect:/form";
}
// In the redirect target
@RequestMapping(method = RequestMethod.GET)
public String showForm(HttpSession session, Model model) {
    Object data = session.getAttribute("tempData");
    if (data != null) {
        model.addAttribute("data", data);
        session.removeAttribute("tempData");
    }
    return "form";
}

While powerful, this method adds complexity to session management and may impact application scalability.

Best Practice Recommendations

Based on the above analysis, we propose the following comprehensive recommendations:

1. Prioritize Security: Always avoid exposing sensitive data in URLs, even if encrypted or encoded. Redirect parameters should only contain necessary, non-sensitive state information.
2. Design for Explicitness: Explicitly specify redirect behavior in controllers, avoiding reliance on framework defaults. When using RedirectView, always set the exposeModelAttributes property explicitly.
3. Adapt to Versions: For Spring MVC 3.0.2 and later, monitor official fixes for SPR-6464 and consider upgrading to versions with built-in support.
4. Reuse Code: Encapsulate safe redirect logic into utility classes or base classes to reduce duplication. For example:

   public abstract class BaseController {
       protected View safeRedirect(String url) {
           RedirectView rv = new RedirectView(url);
           rv.setExposeModelAttributes(false);
           return rv;
       }
   }

5. Ensure Test Coverage: Write unit and integration tests for redirect logic to verify that model attributes are handled correctly and URL generation meets expectations.

Conclusion

The issue of redirect parameter exposure in Spring MVC is a classic case of misalignment between framework behavior and business requirements. By deeply understanding how RedirectView works and leveraging solutions from SPR-6464, developers can effectively control how model data propagates, balancing functional needs with security constraints. In practice, it is advisable to choose the most suitable strategy based on data sensitivity, application architecture, and team habits, continuously optimizing implementations as the Spring framework evolves.