How to properly secure DAM assets

Hi @garimak,

Here’s the recommended approach for keeping DAM assets secure on Publish in AEM as a Cloud Service. Short version: don’t rely on ACLs alone- enforce authentication at Sling + Dispatcher, and make sure nothing gets cached publicly.

What to do (battle-tested setup)

1. Require login for the secure path (Sling)

   • Put your protected assets under a single root, e.g. /content/dam/secure.

   • Apply CUG on that path (group(s) allowed). This sets jcr:read properly and marks the subtree as auth-required.

   • Alternatively (or additionally), configure Sling Authentication Requirements to require auth for /content/dam/secure(/.*)?.

2. Enforce auth at the edge (Dispatcher)

   • In dispatcher.filters, deny anonymous access to /content/dam/secure/* (including renditions like /jcr:content/renditions/*, /cqdam/*, /thumbnails/*).

   • Enable Dispatcher auth_checker for that path so Dispatcher calls a permission check endpoint (e.g. /bin/permissioncheck) and only serves the asset if the user is authenticated and authorized.

   • In dispatcher.cache.rules, do not cache anything under /content/dam/secure/*. Also set response headers (Cache-Control: private, no-store) for those assets from Publish.

3. CDN alignment

   • Ensure CDN honors origin headers (no-store/private) for these paths, or configure a CDN rule to bypass caching for /content/dam/secure/*.

4. Publishing strategy

   • If assets are truly internal (never visible on the public site), the simplest is don’t publish them at all—keep them on Author (accessible via VPN/VPC/enterprise auth) or serve to apps via Assets HTTP API with OAuth (service-to-service).

   • If you must deliver to logged-in site users on Publish, follow steps 1–3. ACLs will still replicate, but the protection comes from auth gating + no caching.