The Fortress at the Gate: Mastering AEM Dispatcher Security

Read Time: 5 Minutes

In the world of Adobe Experience Manager (AEM), the Dispatcher is more than just a load balancer or a caching tool—it is your first line of defense. Sitting squarely between the public internet and your AEM publish instances, it is the gatekeeper that decides who gets in and what gets blocked.

If you are running an AEM website, securing the Dispatcher isn’t optional; it’s critical. Based on Adobe’s official checklists and industry best practices, here is your essential guide to locking down your AEM Dispatcher.

1. The Golden Rule: Allowlist > Blocklist

The single most important philosophy for Dispatcher security is the Allowlist (Whitelist) model.

Many legacy configurations relied on “Blocklists”—trying to list every bad URL or malicious pattern to deny. The problem? You can’t predict every attack vector. Instead, configure your Dispatcher to deny everything by default and only explicitly allow what is necessary.

• How to do it: In your dispatcher.any file, the first rule in your /filter section should be a deny for the root path /. Every subsequent rule should be an allow for specific content paths (like /content, /etc/designs), extensions, or selectors.

2. Lock Down Administrative Access

Your administrative consoles (CRXDE, Web Console, System Console) should never be accessible from the public internet. While strong passwords are a must, the Dispatcher ensures these login pages aren’t even visible to the outside world.

• The Checklist:
  • Block access to /crx/* and /system/*.
  • Block access to /admin/*.
  • Ensure the .form selector is disabled to prevent form-based entry points that aren’t strictly necessary.

3. Mitigate Denial of Service (DoS) Attacks

AEM can be resource-intensive when generating pages. Attackers know this and may try to overwhelm your publish instances by requesting infinite variations of URLs (e.g., adding random query parameters or bogus selectors).

• Restrict Query Parameters: Use the /ignoreUrlParams section to ignore all query parameters by default (*), and only allow the specific ones your application needs (like q for search or utm_ tags for tracking). This allows the Dispatcher to cache the page once, rather than bypassing the cache for every unique parameter.
• Limit Extensions: Configure filters to only allow specific mime types (e.g., .html, .jpg, .json, .pdf). If an attacker requests .php or .exe, the Dispatcher should block it instantly before it reaches AEM.
• Node Paths: Prevent access to /etc/ and /libs then create filters to allow specific paths:
  • /etc/designs/*
  • /etc/clientlibs/*
  • /etc/segmentation.segment.js
  • /libs/cq/personalization/components/clickstreamcloud/content/config.json
  • /libs/wcm/stats/tracker.js
  • /libs/cq/personalization/*
  • /libs/cq/security/userinfo.json
  • /libs/granite/security/currentuser.json
  • /libs/cq/i18n/*
• JSON Depth: If you expose JSON data, limit the depth of the node tree that can be requested to prevent attackers from dumping your entire repository in one massive request.

4. Encryption and Transport

It goes without saying in 2025, but HTTPS is mandatory.

• End-to-End Encryption: Enable HTTPS not just for the public facing site, but also for the transport layer between the Dispatcher and the AEM Publish instances.
• Cookie Security: Ensure the secure and HttpOnly flags are set on your cookies to prevent them from being intercepted or accessed by client-side scripts.
• Clickjacking Prevention: Configure your web server (Apache/IIS) to send the X-FRAME-OPTIONS: SAMEORIGIN header. This prevents your site from being loaded in an iframe on a malicious site.

5. Architectural Hygiene

Security often overlaps with simple “clean” architecture. A well-organized Dispatcher setup is easier to audit and harder to breach.

• Dedicated System User: Run the Dispatcher (Apache/IIS) module as a dedicated, least-privileged system user. It should strictly have write access only to the cache directory and read access to configuration files.
• Separate Author vs. Publish: Never share the same dispatcher.any file for Author and Publish instances. The Author instance requires open paths (for editing) that would be a major vulnerability on Publish. Maintain distinct configuration files.
• Modular Configs: Instead of one massive configuration file, break your rules into smaller, modular files (e.g., filters.any, rules.any). This makes it easier for developers to review changes without missing a critical security hole in a wall of text.

6. The “Human” Element

Finally, automation and process are key.

• Automated Scanning: Use tools like the Dispatcher Optimizer Tool (DOT) or SecureAEM to automatically scan your configurations for known vulnerabilities.
• Penetration Testing: Before any major go-live, perform a penetration test. No amount of checklist reading beats a white-hat hacker actively trying to break your specific implementation.

Conclusion

AEM Dispatcher security is not a “set it and forget it” task. It requires a proactive stance—denying by default, minimizing the attack surface, and keeping your software up to date. By following these guidelines, you ensure that your Dispatcher remains a fortress, delivering content swiftly while keeping the bad actors at bay.

---

How Infinium Technologies Can Help

Securing an enterprise-grade AEM ecosystem requires deep expertise in both application structure and network infrastructure. At Infinium Technologies, we specialize in ensuring your AEM platform is robust, compliant, and performant.

Whether you need a comprehensive security audit, a Dispatcher configuration overhaul, or ongoing DevOps support to implement these best practices, our team has the experience to help you stay secure.

Ready to lock down your AEM environment? Contact us today at to discuss your security needs.