Hi Community,
I’ve restricted access to /content/dam/secure/ using ACLs, which work fine on Author, but after replication the assets are still accessible on Publish via direct URLs.
What is the recommended best practice in AEM as a Cloud Service to ensure DAM assets remain secure on Publish - ACL replication, CUGs, Dispatcher filters, or another approach?
Solved! Go to Solution.
Views
Replies
Total Likes
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)
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(/.*)?.
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.
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/*.
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.
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)
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(/.*)?.
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.
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/*.
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.
Views
Likes
Replies