Restrict direct browser access to DAM folders in Adobe Experience Manager

Adobe Experience Manager (AEM) may allow direct browser access to assets in DAM folders when permissions and Dispatcher filters aren’t explicitly restricted. To resolve the issue, restrict repository permissions and Dispatcher access for the protected DAM paths while allowing authenticated microservices to access the required assets.

Description description

Environment

Adobe Experience Manager (all supported versions)

Issue/Symptoms

  • Certain DAM folders can be accessed directly through a web browser, allowing files such as CSVs or other assets to be downloaded by anyone who knows the URL.
  • Files in specific DAM folders, for example, /content/dam/<folder>/example.csv, can be accessed and downloaded directly through a browser.
  • Direct browser access must be restricted while authorized microservices retain access to the required assets.

Root cause

By default, DAM folders may be accessible to anonymous users if permissions and Dispatcher filters aren’t explicitly restricted.

Resolution resolution

Follow the steps below to resolve the issue:

  1. Harden repository permissions using AEM ACLs:

    1. In AEM Author, go to Tools > Security > Permissions.
    2. For groups representing public or anonymous users, deny read access to the sensitive DAM folders, for example, /content/dam/<folder>.
    3. Create a technical or service user with jcr:read permissions only on these folders.
    4. Configure the microservices to authenticate as this technical user when accessing the assets.
  2. Block direct public URLs at the Dispatcher:

    • In the Dispatcher configuration, add deny rules for the DAM paths you want to protect. Place these rules after the global deny and before broad allow rules.

    • Use the following example configuration:

      code language-none
      /filter {
      # Deny direct access to DAM subtree
      /0200 { /type "deny" /method "GET" /path "/content/dam//*" }
      }
      

    With these rules, browsers receive 403 or 404 errors for direct access, while microservices can use an internal vhost or API endpoint with different Dispatcher rules and technical user credentials.

  3. Verify the solution:

    • Attempt to access a protected asset through a browser and confirm that access is denied.
    • Confirm that microservices configured with the technical user can still access the required assets.
recommendation-more-help
experience-cloud-kcs-help-kbarticles