Apache Tomcat PreResources and PostResources

How PreResources and PostResources change Tomcat resource resolution

Tomcat evaluates these resource links in a predictable order, so they can alter which file an application sees at runtime. That matters because the same path can resolve to different content depending on whether Tomcat checks the linked resource before or after the webapp’s own files.

PreResources are useful when an operator needs Tomcat to surface shared or externally managed content ahead of the application package, while PostResources provide a fallback layer after the application’s own resources have been checked. The ordering is the security-relevant part: precedence determines whether an app reads the intended file or an injected one.

Why resource precedence matters for application behaviour

Resource ordering can affect static assets, configuration files, templates, and other application-visible content. If a PreResources entry shadows an application file, the application may behave as though its packaged content were replaced. If a PostResources entry is used, the application’s own files still win first, and the linked resource is only consulted when the app does not supply that path.

This makes the feature powerful, but also easy to misuse. A small change in resource order can produce inconsistent behaviour across environments, especially when administrators assume that linked resources are simply additive rather than precedence-bearing.

Security implications of exposing additional files through Tomcat

Because these links extend what the application context can see, they can broaden the attack surface if the mapped files include secrets, administrative material, or writable content. A linked resource that should only supplement content can instead become a path for unexpected disclosure or content substitution if ownership, permissions, and placement are not tightly controlled.

When used deliberately, the feature can also support safer separation of deployment artefacts from shared content. The key control question is not whether Tomcat can load extra resources, but whether the linked files are trustworthy, read-only where appropriate, and isolated from untrusted modification.

Operational patterns and safe use cases

Administrators commonly use this mechanism for externalised content, shared libraries, environment-specific overrides, or content that must live outside the application archive. In those cases, the resource link should be treated as part of the application’s trusted configuration surface, not as a convenience feature to be added casually.

For security-sensitive deployments, the safest pattern is to keep the linked path narrow, document why precedence is needed, and verify that the application still resolves critical files from the intended location. A concise Tomcat hardening reference can help here, especially where resource mapping sits alongside broader server controls like connector settings and file-access restrictions, as outlined in Apache Tomcat Hardening Guide.

Risk and Threat Considerations

PreResources and PostResources create a trust boundary inside the application context, so mistakes can lead to file shadowing, unintended disclosure, or the use of attacker-influenced content. The greatest risk appears when linked resources are writable, come from less trusted locations, or are assumed to be harmless because they sit outside the webapp archive.

Failure mechanism: An application resolves the wrong resource because precedence causes Tomcat to prefer a linked file over the packaged file, or because a linked file is modified after deployment.

Impact: The application may serve altered pages, load unsafe configuration, expose sensitive material, or behave inconsistently in ways that are hard to detect during routine testing.

Practitioner Guidance

Why practitioners should care: Treat these links as a deployment control, not just a filesystem convenience. The same mechanism that supports clean content separation can also silently override application assumptions, so ownership of the linked path and the resolution order must be explicit.

What to watch for: Review any use of PreResources first, because it changes default lookup precedence and can mask packaged files. Use PostResources more conservatively when you only need fallback content, and confirm that linked material is read-only or otherwise protected from unexpected change.

Practitioner takeaway: If a resource link can change which file the app sees, it belongs in the same change-control and hardening conversation as other runtime configuration.

Related resources from NHI Mgmt Group

• How should security teams harden Apache Tomcat when management consoles are exposed to the internet?
• How should security teams reduce exposure to CVE-2025-24813 in Apache Tomcat before patching is complete?
• What breaks in practice when Apache Tomcat handles partial PUT paths incorrectly?
• What breaks when Apache Tomcat manager access is left exposed with weak credentials?