Security and Delivery

Defence in layers

No single control protects an AEM site. Each layer stops a different class of problem:

1. CDN traffic filter rules — block, rate-limit or log requests at the edge, before they cost you anything.
2. WAF rules — pattern-based detection of SQL injection, XSS and similar. Separately licensed.
3. Dispatcher filters — default-deny path filtering (day 6).
4. Repository ACLs — what an authenticated user may see and do (day 31).
5. Application code — HTL escaping, CSRF, careful servlet binding (days 15 and 32).

Traffic filter rules

These live in config/cdn.yaml in your repository and deploy through a config pipeline — deliberately separate from the application pipeline so you can respond to an incident in minutes.

kind: CDN
version: "1"
metadata:
  envTypes: ["dev", "stage", "prod"]
data:
  trafficFilters:
    rules:
      - name: block-admin-paths
        when:
          reqProperty: path
          matches: "^/(system|crx|bin/querybuilder).*"
        action: block

      - name: rate-limit-search
        when:
          reqProperty: path
          equals: /search
        action:
          type: log
          rateLimit:
            limit: 100
            window: 10

Actions available:

• allow — explicitly permit, short-circuiting later rules.
• block — reject with 406 (or a configured status).
• log — record without blocking. Always start here.

Conditions can match on path, method, query parameters, headers, client IP, country and more, combined with allOf and anyOf.

WAF rules

WAF rules add managed, pattern-based protection: SQL injection, cross-site scripting, command injection, known-bad user agents and scanner signatures. They require the WAF-DDoS Protection licence and are configured in the same cdn.yaml under wafRules.

The same discipline applies: enable in log mode, review what matches, then enforce. WAF false positives on legitimate content are common — a CMS routinely carries text that looks like an injection attempt.

Rate limiting and DoS

Adobe's CDN absorbs volumetric attacks by default. Your job is application-level abuse: a search endpoint hit thousands of times a minute, a form submitted repeatedly, an expensive query in a loop. Rate-limiting rules with a limit and a window handle these, and are worth applying to any endpoint that triggers a query or a write.

Custom domains and certificates

To serve your site on your own domain:

1. Add the domain in Cloud Manager and prove ownership with the DNS TXT record it provides.
2. Provide a certificate. Either an Adobe-managed certificate — provisioned and renewed automatically, the sensible default — or bring your own, which you must then renew yourself.
3. Point DNS at the CNAME Cloud Manager gives you.
4. Wait for propagation and verify.

You can also front AEM with your own CDN. Doing so means you take on caching, TLS and security configuration, and you must forward the headers Adobe expects — a meaningful amount of ownership in exchange for control.

Practical hygiene

• Verify /system/console, /crx/de and .infinity.json are unreachable through the Dispatcher on every environment.
• Rate-limit anything that queries or writes.
• Keep secrets in Cloud Manager secret variables, never in Git.
• Review Dispatcher filters whenever you add an endpoint.
• Watch CDN logs for what your rules are matching, not just for attacks.