Protecting content in AEM Headless

Ensuring the integrity and security of your data when serving AEM Headless content from AEM Publish is crucial when serving sensitive content. This how-to walks through securing the content served by AEM Headless GraphQL API endpoints.

The guidance in this tutorial where there are stringent requirements for content to be exclusively available to specific users or user groups. It is imperative to distinguish between personalized marketing content and private content, such as PII or personal financial data, to avoid confusion and unintended outcomes. This tutorial addresses protecting private content.

When discussing marketing content, we are referring to content tailored for individual users or groups, which is not intended for general consumption. However, it’s essential to understand that while this content may be targeted for certain users, its exposure outside the intended context (e.g., through manipulation of HTTP requests) does not pose a security, legal, or reputational risk.

It is emphasized that all content addressed in this article is assumed to be private, and may only be viewed by designated users or groups. Marketing content often does not require protection, rather its delivery to specific users can be managed by the application, and cached for performance.

This how-to does not cover:

User groups

First, we must define a user group containing the users that should have access to the protected content.

{align="center"}

User groups assign access to AEM Headless content, including Content Fragments or other referenced assets.

If various levels of access are required, create multiple user groups which can be associated with different content.

Adding users to user groups

To grant AEM Headless GraphQL API requests access to protected content, you can associate the headless request with a user belonging to a specific user group. Here are two common approaches:

Protecting Content Fragments

Protecting Content Fragments is essential for safeguarding your AEM Headless content and is achieved by associating the content with a Closed User Group (CUG). When a user makes a request to the AEM Headless GraphQL API, the content returned is filtered based on the user’s CUGs.

{align="center"}

Follow these steps to achieve this through Closed User Groups (CUGs).

Perform these same steps for all folders containing Content Fragments that need to be protected, applying the correct CUGs to each folder.

Now, when an HTTP request is made to the AEM Headless GraphQL API endpoint, only the Content Fragments accessible by the requesting user’s specified CUGs will be included in the result. If the user lacks access to any Content Fragment, the result will be empty, albeit still returning a 200 HTTP status code.

Protecting referenced content

Content Fragments often reference other AEM content such as images. To secure this referenced content, apply CUGs to the asset folders in which the referenced assets are stored. Note that referenced assets are commonly requested using methods distinct from those of the AEM Headless GraphQL APIs. Consequently, the manner in which access tokens are passed on requests to these referenced assets may differ.

Depending on the content architecture, it may be necessary to apply CUGs to multiple folders to ensure all referenced content is protected.

Prevent caching of protected content

AEM as a Cloud Service caches HTTP responses by default for performance enhancement. However, this can cause issues with serving protected content. To prevent caching of such content, remove cache headers for specific endpoints in the Apache configuration of the AEM Publish instance.

Add the following rule to your Dispatcher project’s Apache configuration file to remove cache headers for specific endpoints:

# dispatcher/src/conf.d/available_vhosts/example.vhost

<VirtualHost *:80>
    ...
    # Replace `example` with the name of your GraphQL endpoint's configuration name.
    <LocationMatch "^/graphql/execute.json/example/.*$">
        # Remove cache headers for protected endpoints so they are not cached
        Header unset Cache-Control
        Header unset Surrogate-Control
        Header set Age 0
    </LocationMatch>
    ...
</VirtualHost>

Note that this will incur a performance penalty as the content will not be cached by the dispatcher or CDN. This is a trade-off between performance and security.

Protecting AEM Headless GraphQL API endpoints

This guide does not address securing the AEM Headless GraphQL API endpoints themselves, but rather focuses on securing the content served by them. All users, including anonymous users, can access the endpoints containing protected content. Only the content accessible by the user’s Closed User Groups will be returned. If no content is accessible, the AEM Headless API response will still have a 200 HTTP response status code, but the results will be empty. Typically, securing the content is sufficient, as the endpoints themselves do not inherently expose sensitive data. If you need to secure the endpoints, apply ACLs to them on AEM Publish via Sling Repository Initialization (repoinit) scripts.