The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →For a secure Apache Struts application, first move to a current, maintained release, then harden production settings, constrain request binding, treat OGNL as a security boundary, and test the result against real application workflows. Struts is a web framework, not a complete application security system: authorization, safe input handling, and deployment controls remain your responsibility.
1. Start with a maintained Struts release
Check Apache’s release information, download page, and security guidance before choosing or upgrading a version. Release availability and security advisories change, so treat these pages—not a remembered version number—as the authority for an upgrade decision.
As of October 4, 2026, Apache’s releases page identified Struts 7.4.0 as “best available”; its download page listed 7.4.0 and 6.12.0. The release lines have different platform requirements, so compare the target release’s own notes with your application’s Java and web-platform dependencies before planning a migration.
| Release line listed by Apache on October 4, 2026 | Platform requirements described in Apache announcements | What to check before adopting it |
|---|---|---|
| 7.4.0, identified as “best available” | Struts 7.x requires Java 17 and Jakarta EE. | Confirm your Java runtime, Jakarta-based dependencies, plugins, and application configuration are compatible with the target release. |
| 6.12.0, also listed on the download page | Struts 6.x requires Servlet API 3.1, JSP API 2.1, and Java 8. | Check the target release notes and assess whether this line fits your platform and support needs; the listing alone does not establish a particular application’s migration path. |
These platform requirements are release-line guidance, not a substitute for version-specific migration notes. Apache lists source archives, distributions, examples, libraries, and documentation on its download page. Prefer official downloads or Maven artifacts, and verify downloaded files using the signatures Apache provides rather than relying on an unofficial mirror.
#1 Best Overall
Plan a move off end-of-life branches
Apache says it no longer supplies security patches, bug fixes, or updates for a branch after it reaches end of life. Its EOL list gives these dates:
- Struts 2.5.x: October 30, 2023.
- Struts 2.3.x: September 12, 2019.
- Struts 1.x: April 5, 2013.
Versions absent from current download listings also receive no further project security patches, according to Apache’s download guidance. Treat migration from an EOL branch as a priority. If an immediate move is not feasible, any third-party extended support is a temporary risk-management measure: verify its coverage and terms, and do not assume it is an Apache-backed service.
2. Set production configuration deliberately
Development conveniences and diagnostic features can expose internals or create avoidable attack paths. Review production configuration as part of every deployment, including settings inherited from shared configuration files.
Rank #2
- Turn off development mode. Set
struts.devModetofalsein production. Apache warns that devMode can expose application internals and evaluate risky parameter expressions. It is disabled by default, but an explicit setting instruts.xmlcan enable it. See Apache’s devMode guidance. - Block direct JSP access. Put JSPs under
WEB-INFand add a web security constraint; Apache recommends using both. Since Struts 7.2.0, the framework logs a warning if JSP tags are accessed directly outside an action scope, but a warning is not a substitute for blocking access. - Keep Config Browser out of production where possible. If the plugin must remain, limit access with authentication or another security mechanism.
- Reduce framework log verbosity. Apache suggests INFO or less for production, with WARN for framework classes as one option. Keep enough application logging for incident response without exposing sensitive data.
- Use UTF-8 consistently. Align application, request, response, and page character encoding to avoid inconsistent handling of user input and output.
- Separate access levels by namespace. Put actions with different access requirements in separate namespaces. Do not rely on URL-pattern access controls when one namespace mixes different security levels.
- Define custom error pages. Apache notes that automatically generated error pages can expose action names without escaping them. Use controlled error handling instead of displaying framework-generated details to users.
3. Limit what request parameters can reach
Request binding turns attacker-controlled parameter names and values into calls against application properties. Make the set of bindable properties intentional and narrow, rather than exposing a large domain object graph.
- Require explicit injection points. Apache’s security guidance says
struts.parameters.requireAnnotations=trueis available from Struts 6.4 and enabled by default from 7.0. Annotate only intended injection points with@StrutsParameter. - Use the minimum nesting depth. Expose only the depth needed for the form or request. A nested getter should return a purpose-built DTO or a DTO collection, not a live Hibernate object, container, Spring-managed bean, service, or object graph with setters that perform other work.
- Separate request models from persistence models. Use form/request DTOs rather than binding directly to database entities. This limits the properties a request can alter and avoids making persistence-layer behavior reachable through setters.
- Review each exposed setter and property. Confirm the request needs to write it, and inspect any side effects. Treat nested properties as additional attack surface, not as harmless convenience.
These restrictions can affect existing forms and integrations. Inventory binding behavior and test legitimate requests when tightening annotations or depth, rather than broadening access again to make a failing workflow pass.
4. Treat OGNL and expression evaluation as security-sensitive
OGNL is used in Struts expression handling; application-controlled or request-derived content should not be allowed to become an expression. Apache recommends enabling the OGNL allowlist capability, which is available since 6.4 and enabled by default from 7.0. Its security page also describes restricting ActionContext access, limiting expression length (the documented default is 256 characters), and applying additional restrictive settings.
Do not paste untrusted request values into forced %{...} evaluation or localization calls such as getText(...). Apache warns that message parameters are evaluated, so a value intended to be displayed can instead be interpreted. Keep expressions and message keys under application control; pass untrusted values as data, not as expression text.
OGNL restrictions are not guaranteed to be drop-in for every application: stronger safeguards may break functionality. Test the application’s UI and behavior comprehensively before enabling restrictive settings in production, and resolve compatibility problems by finding the affected expression or binding rather than weakening controls without review.
Free tools Windows power users keep installed
One-click scans. No signup required.
5. Render untrusted values safely
Output encoding must match the rendering context. Use Struts tags where appropriate rather than raw JSP EL for untrusted values, and ensure displayed user content is escaped. Avoid assuming a value is safe because it has already passed through request binding or localization; those stages do not make it safe for HTML output.
Rank #4
Pair safe rendering with the custom error pages described above. Error handling should not reflect unescaped action names, exception details, or other internal data into a browser response.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.6. Add browser-level defenses without mistaking them for authorization
Apache’s security guidance describes Fetch Metadata as a mitigation for common cross-origin attacks such as CSRF, implemented through a Struts interceptor. It also discusses COOP/COEP isolation. These controls need endpoint-aware configuration; there is no universal policy established for every application.
Assess which endpoints should accept cross-origin requests and how isolation affects legitimate integrations. These headers or interceptor controls do not replace authorization checks or a separate review of CSRF protections.
7. Verify hardening with an application-specific checklist
Before release, review the configuration and test expected workflows, including those involving nested request objects or expressions. A useful deployment gate is:
- Release and security advisories checked against Apache’s current pages; target-version requirements confirmed against the runtime and platform.
- Production configuration has devMode disabled; direct JSP requests are blocked; Config Browser is absent or access-restricted.
- Logging, character encoding, namespace boundaries, and custom error handling match the production design.
- Parameter injection is explicit, annotations cover only intended properties, and nesting stops at the minimum necessary DTO depth.
- OGNL allowlisting and any additional restrictions are enabled as appropriate, with tests covering both security-sensitive and ordinary expression-dependent flows.
- Rendered user-controlled values are escaped in their output context, and cross-origin controls have been checked against endpoint behavior.
Apache identifies its user mailing list and issue tracker as the project-hosted support options for supported versions; check the releases page for current details. For version-specific migrations, consult the target release’s notes and migration documentation alongside the security guidance, because compatibility depends on the application’s plugins, Java and web platform, and existing configuration.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
