Expand my Community achievements bar.

Submissions are now open for the 2026 Adobe Experience Maker Awards.
SOLVED

Inquiry About Access Restrictions for AEM Edge Delivery Services

Avatar

Level 2

I’m new to the AEM Edge Delivery System and would like to understand how to restrict access to preview and live pages.

When using an AEM Sites project (wknd), users are required to log in to access pages:
author-pXXXXXX-eXXXXXX.adobeaemcloud.com/content/wknd/us/en.html

However, when using Edge Delivery Services (EDS) with AEM, the preview URL looks like:
<branch>--<repo>--<owner>.aem.page/content/<site-name>
and is publicly accessible to anyone who knows the link.

How can I restrict unauthorized users from viewing or deleting content in this setup?
At the moment, I’m able to delete or unpublish content using Sidekick without any authentication.

Is there an IP allow list or login mechanism available, similar to what AEM author environments provide?
Or is there a configuration in the GitHub repository that I need to set up?

Any guidance would be greatly appreciated. Thank you!

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @Ben_Hu,

AEM Edge Delivery Services (EDS) preview and live URLs (e.g., branch--repo--owner.aem.page) are publicly accessible by default, unlike AEM Sites author instances. Here's a breakdown of how you can restrict access and protect content/actions in EDS:

1. Restricting Preview Access
Enable Authentication for Preview

EDS does not support built-in Adobe authentication like AEM Sites (e.g., via Adobe IMS), but you can restrict preview access using:

GitHub Private Repositories

  • Make your GitHub repo private.

  • This ensures that only authorized GitHub users can access or push content via Sidekick.

  • However, this does NOT restrict page preview access to *.aem.page URLs.

Use a Preview Environment Proxy

Set up a reverse proxy (e.g., Cloudflare, NGINX) in front of the preview domain and apply:

  • IP allowlisting

  • Basic Auth

  • JWT/Auth0 if more robust login is needed

Adobe’s *.aem.page domains cannot be customized with IP allow lists directly — you’d need to place a proxy in front.

2. Restricting Content Deletion / Publishing via Sidekick

By default, Sidekick actions like "Publish", "Unpublish", "Delete":

  • Are linked to GitHub commits, not gated by Adobe auth.

  • Anyone with access to the Sidekick URL and repo write access can trigger these.

Secure these actions:
Use GitHub Branch Protection Rules
  • Prevent force pushes to main/live branches.

  • Require pull requests + code review to merge.

  • Disable GitHub Actions for non-admin contributors.

Restrict GitHub Write Access
  • Make the repo private.

  • Limit collaborator permissions (read-only or PR-only).

Customize Sidekick Actions

In your config.json or sidekick.config.js, you can:

  • Remove or restrict Sidekick buttons (e.g., delete, unpublish) from non-admins.

  • Example: Remove “delete” action for all but you:

if (context.user !== 'your-username') {
  delete config.actions.delete;
}
3. IP Allowlisting / Access Control

Unfortunately, the *.aem.page domain doesn’t offer native IP restrictions from Adobe. Workaround options:

Use an Edge Proxy with Access Control
  • Deploy a custom proxy (Cloudflare Workers, Fastly, or NGINX)

  • Route requests to *.aem.page

  • Enforce:

    • IP restrictions

    • Basic authentication

    • Token-based headers


Santosh Sai

AEM BlogsLinkedIn


View solution in original post

5 Replies

Avatar

Correct answer by
Community Advisor

Hi @Ben_Hu,

AEM Edge Delivery Services (EDS) preview and live URLs (e.g., branch--repo--owner.aem.page) are publicly accessible by default, unlike AEM Sites author instances. Here's a breakdown of how you can restrict access and protect content/actions in EDS:

1. Restricting Preview Access
Enable Authentication for Preview

EDS does not support built-in Adobe authentication like AEM Sites (e.g., via Adobe IMS), but you can restrict preview access using:

GitHub Private Repositories

  • Make your GitHub repo private.

  • This ensures that only authorized GitHub users can access or push content via Sidekick.

  • However, this does NOT restrict page preview access to *.aem.page URLs.

Use a Preview Environment Proxy

Set up a reverse proxy (e.g., Cloudflare, NGINX) in front of the preview domain and apply:

  • IP allowlisting

  • Basic Auth

  • JWT/Auth0 if more robust login is needed

Adobe’s *.aem.page domains cannot be customized with IP allow lists directly — you’d need to place a proxy in front.

2. Restricting Content Deletion / Publishing via Sidekick

By default, Sidekick actions like "Publish", "Unpublish", "Delete":

  • Are linked to GitHub commits, not gated by Adobe auth.

  • Anyone with access to the Sidekick URL and repo write access can trigger these.

Secure these actions:
Use GitHub Branch Protection Rules
  • Prevent force pushes to main/live branches.

  • Require pull requests + code review to merge.

  • Disable GitHub Actions for non-admin contributors.

Restrict GitHub Write Access
  • Make the repo private.

  • Limit collaborator permissions (read-only or PR-only).

Customize Sidekick Actions

In your config.json or sidekick.config.js, you can:

  • Remove or restrict Sidekick buttons (e.g., delete, unpublish) from non-admins.

  • Example: Remove “delete” action for all but you:

if (context.user !== 'your-username') {
  delete config.actions.delete;
}
3. IP Allowlisting / Access Control

Unfortunately, the *.aem.page domain doesn’t offer native IP restrictions from Adobe. Workaround options:

Use an Edge Proxy with Access Control
  • Deploy a custom proxy (Cloudflare Workers, Fastly, or NGINX)

  • Route requests to *.aem.page

  • Enforce:

    • IP restrictions

    • Basic authentication

    • Token-based headers


Santosh Sai

AEM BlogsLinkedIn


Avatar

Level 2

@SantoshSai 

Thanks for the response.

However, I have a question regarding the following point:

GitHub Private Repositories

This ensures that only authorized GitHub users can access or push content via Sidekick.

My GitHub repository is already set to private, but I’m still able to delete a page under the following conditions:

  • When I click “Edit” on Sidekick, it opens the Adobe login page.

  • Even if I don’t log in, the "Delete" button still appears in Sidekick.

  • Then click "Delete," the page becomes a 404.

  • However, when I check the content in AEM, the page still exists.

Could there be a misconfiguration on my side that prevents proper authentication or deletion behavior?
01.jpg02.jpg03.jpg

Avatar

Community Advisor

Hi @Ben_Hu 

When you delete the page, page is deleted from S3 bucket which the EDS content-hub, where all the content markup is stored.
you can check the EDS architecture here : https://github.com/adobe/helix-home/blob/main/docs/architecture.md 

Arun Patidar

AEM LinksLinkedIn

Avatar

Level 2

Thanks for the reply and the structural information — I really needed that.

However, my question is about the statement on this sidekick page https://www.aem.live/docs/sidekick, which says:

Signing in is not required to use the Sidekick to switch between environments and preview or publish content. However, if you wish to unpublish and delete pages, you must sign in.

But apparently, I’m able to delete pages without signing in.

Does this count as a bug, or is it intentionally designed this way, despite what the documentation says?

Avatar

Community Advisor

Adobe is working on a solution to restrict direct preview and live url. Please keep check the updated from them.

Join EDS discord channel for queries/updates : https://discord.com/channels/1131492224371277874/1144495462255185971 

Arun Patidar

AEM LinksLinkedIn