Dispatcher as the First Line of Defense

Together with caching and load balancing, security is the third major responsibility of the AEM Dispatcher. It acts as a protective shield in front of your AEM Publish instances, inspecting incoming requests and rejecting anything that doesn’t meet your configured rules before it reaches the application layer.

This is essential because AEM exposes a number of internal endpoints by default, many of which should never be accessible publicly. Properly configured, the Dispatcher serves as a firewall, allowing only the specific URLs, file types, and query patterns that your site requires.

Filtering with Dispatcher

Dispatcher uses filter rules, defined in the dispatcher.any configuration file, to determine what requests are allowed or denied. Adobe’s default configuration denies most internal paths, like /apps/, /libs/, /system/, and servlet endpoints like /bin/querybuilder.json, while allowing access to expected public-facing paths like /content/*.

These filters should be refined further per project. For example:

• Blocking authoring tools such as /editor.html, /cf#, and /crx/de on publish
• Allowing only specific selectors (.html, .json, .model.json) as needed
• Denying access to suspicious query strings or deeply nested paths

Filtering helps mitigate various attack vectors by minimizing the AEM surface area exposed to the web. It's an essential technique for preventing misuse of internal servlets or unauthorized data exposure.

Security by Caching and Rejection

Dispatcher’s security benefit is amplified when combined with its caching behavior. Cached content can be served repeatedly without reaching AEM, reducing the chance of overwhelming the backend (a basic form of DoS mitigation). Meanwhile, any request that isn’t explicitly allowed by filters can be blocked at the Apache/Dispatcher layer, saving AEM from doing unnecessary work.

This model supports a secure-by-default posture. Even if AEM is vulnerable at a specific endpoint, it’s safe as long as that endpoint isn’t exposed through Dispatcher.

Apache Integration for Edge Hardening

Dispatcher is typically deployed with Apache HTTPD, which allows further security hardening at the edge. Common practices include:

• Terminating SSL at the Apache level
• Enforcing IP allow/deny rules
• Adding basic authentication on sensitive URLs
• Appending or enforcing security headers (e.g., X-Frame-Options, Content-Security-Policy, Strict-Transport-Security)

These features are configured outside of AEM and ensure your edge server contributes meaningfully to your security strategy.

Supporting CSRF and Clickjacking Protections

While CSRF protection is primarily handled by AEM’s token system, Dispatcher plays a supporting role:

• Ensures that CSRF token endpoints (e.g., /libs/granite/csrf/token.json) are reachable
• Prevents token caching issues by bypassing cache rules for such endpoints

For clickjacking protection, you can configure Apache to append X-Frame-Options: DENY or use modern headers via mod_headers to secure your site against iframe injection.

Practical Recommendations

• Always block internal paths on publish, never assume AEM will do it for you.
• During development, proactively test routes that should and shouldn’t be accessible.
• Maintain a clear allowlist policy, start from deny-all, then explicitly open only what’s needed.
• Regularly audit your filter rules alongside your site structure as new features roll out.

Conclusion

Security at the Dispatcher level is a foundational layer of protection for AEM. By tightly controlling which requests are allowed to reach AEM, you reduce risk, improve performance, and ensure that sensitive endpoints remain protected. Every AEM deployment should treat Dispatcher filtering and edge hardening as a first-class responsibility, just like caching and load balancing.

When designed correctly, Dispatcher becomes a powerful, multi-role component, acting as cache, load balancer, and firewall. It helps your AEM platform stay fast, secure, and resilient in real-world conditions.