Back to tool

AEM Dispatcher Tester & Security Audit — User Guide

This tool simulates how the AEM Dispatcher evaluates your filter and cache rules, and audits them against the Dispatcher Security Checklist. It supports both AEM as a Cloud Service (Dispatcher SDK) and classic AMS / on-prem dispatcher.any — switch with the Target toggle. Everything runs in your browser — nothing is uploaded.

Quick start

  1. Paste your filter rules (the contents of filters/*.any) into the first box — or click Secure sample / Insecure sample.
  2. Optionally paste your cache config (cache/*.any, including /cache { /rules … }) into the second box.
  3. Use the three tabs:
    • Single test — check one URL and read the full rule-by-rule trace.
    • Test suite — run many URLs with expected allow/deny outcomes.
    • Security audit — score your config and run known attack-surface probes.

How evaluation works

The Dispatcher reads rules top-to-bottom and the last matching rule wins. The tool mirrors this and shows a trace: every rule, whether it matched, and why (which property failed). If no rule matches the request filter, the request is denied by default.

What's parsed

Each rule block of the form /0001 { /type "allow" /url "/content/*" } is parsed for:

  • /type — allow or deny.
  • A pattern — from /glob, /url, or /path (first one found).
  • /method, /extension, /selectors, /suffix — optional constraints.

The parser is brace-aware, so it handles nested sections (/filter { … }, /cache { /rules { … } /ignoreUrlParams { … } /headers { … } }), # comments, and quoted values. Unresolved $include references are flagged — paste the included files too (they often contain the default deny rules) for a complete analysis.

Single test & trace

The verdict shows Allowed / Denied for the filter and Cacheable / not for the cache rules, each with the winning rule. Expand the trace to see exactly which rules matched and why the last one won — useful for debugging rule ordering.

Test suite

Build a table of { URL, method, expected } cases (or Import a url,method,expected list, or Load sample suite). Each row shows the actual decision and PASS/FAIL live as you edit your rules. Export results to CSV for code review or CI evidence. This is the fastest way to lock in your filter behaviour against regressions.

Security audit

The audit grades your filter against the Dispatcher Security Checklist and runs a library of known attack-surface probes through your rules:

  • Admin consoles — /crx/de, /system/console
  • Data exfiltration — .infinity.json, deep/selector JSON, /bin/querybuilder.json, feeds, /etc.json
  • Source exposure — /apps, /libs
  • Traversal & write surface — _jcr_content, path traversal, POST to content

It also checks cache hardening (/allowAuthorized, /ignoreUrlParams allow-list, /statfileslevel, /gracePeriod). Each finding includes severity, an explanation, a concrete fix, and a docs link. Anything reported as reachable would not be blocked by your current filter.

AMS / on-prem mode

Switch the Target toggle to AMS / On-prem and paste a classic dispatcher.any. The tool descends into /farms, and for each farm reads its /filter, /cache, /virtualhosts, and /clientheaders. If you paste multiple farms, a farm picker lets you choose which one to test. Request-line globs (GET /content/* *) are honoured, including the embedded HTTP method.

The audit adds AMS-specific checks on top of the shared ones:

  • /allowedClients — flags an open cache-invalidation surface (an allow "*"), or a missing allow-list.
  • /clientheaders — flags a wildcard ("*") that forwards every request header to publish (Host-header injection / cache poisoning).
  • /virtualhosts — notes farms with no hostnames.

Limitations

This is a logic simulator for the common rule properties — it does not run a real Apache + Dispatcher module, evaluate /allowedClients, header/cookie rules, vhosts, mod_rewrite, or stat-file invalidation. Treat results as a fast pre-check and always validate critical rules with the official Dispatcher SDK validator in a non-production environment.

Tips

  • Start with deny * as your first rule and allow specific paths after it — the safest default.
  • Run the Insecure sample through the Security audit to see what a weak filter looks like, then compare with the Secure sample.
  • Keep a test suite of your critical allowed and blocked URLs and re-run it whenever you change rules.