In today’s digital landscape, the security of web applications is a paramount concern for developers and organizations utilizing content management systems like Adobe Experience Manager (AEM). With the increasing prevalence of cyber threats, the imperative to safeguard data and system content has grown exponentially. Failure to maintain adequate security measures can result not only in data breaches but also in significant financial losses and reputational damage.

This article will delve into the critical aspects of AEM security, addressing common vulnerabilities and strategies for their mitigation. We will focus on how architectural solutions at the authoring, publishing, and dispatcher levels can be optimized to enhance security. Additionally, we will explore methods to protect against attacks such as Cross-Site Request Forgery (CSRF) and Distributed Denial of Service (DDoS) attacks, aiming to establish a more robust and secure environment for content management.

Table of contents

1. Basic security tips for Adobe Experience Manager
2. Security at the author level
3. Security at the publish level
4. Security at the dispatcher level
5. Cross-site request forgery (CSRF)
6. DDoS attacks

The world of AEM projects will become even better if every developer has a general understanding of how to protect the platform from data breaches. According to the diagram below, we have an author, several publishers, and two or more dispatchers (often referred to as load balancers). Essentially, these three levels should be prioritized when it comes to data protection. These are classic operational rules widely accepted in the AEM community globally.

Basic security tips for Adobe Experience Manager

• Use HTTPS. AEM is rapidly evolving, providing flexible options for creating authors on a more secure protocol. It’s enough to generate an SSL key using the “SSL Wizard,” create a path to it, and thus utilize a more secure protocol. In Adobe’s recommendations, this step is a top priority for security.
• Install packages with the latest updates. The standard process for developers often involves searching Google while working on components and services. The goal of this step is to regularly monitor Service Packs & Hot Fixes. This helps eliminate many issues, including those related to data security. While it’s not a panacea, it’s essential to keep the system up-to-date.
• Create neat error message pages. If you initially create a page with a brief error description, the client will immediately see what’s not working, while the developer is already in the process of resolving the issue. Logically, this information won’t go unnoticed, helping you avoid client panic, confusion among testers, and misunderstandings in task management.
• Avoid using “admin-admin” for the login and password. While it may sound amusing, the problem of poor-quality login and passwords is quite common even in AEM. In the pursuit of speed or other considerations, we often end up with a highly vulnerable system. Once you discover that simple login credentials have been set, strive to convince your team or management to replace them with more secure ones as soon as possible.

Security at the author level

First, use a VPN. A Virtual Private Network establishes a secure connection between you and the server. This is a simple yet crucial tool: your traffic will be encrypted, making it impossible to trace where you’re sending your data. Thus, with a VPN, no one can access your instance.

This approach is suitable for remote developers and anyone working from various locations with unstable internet connections.

Secondly, your «author» must always be closed off from Google as well. It’s possible to crack the system by guessing the password if the author can be indexed. To check your vulnerability in the search engine, type your domain along with the author and the path to crx. Yes, you can request Yandex or Google to remove such entries from their search results. However, while the issue is being resolved, the system will already be public.

Thirdly, do not underestimate the privileges of the “admin” user, who often has the ability to perform any available operations.

This is especially critical when an employee leaves the company. In many businesses, access to the instance is not personalized but managed through a single admin account. It makes more sense to have individual accounts and be aware of specific changes in the system from particular authors.

In AEM version 6.1, a new approach was introduced that allows specific rights to be assigned for a user’s bundle or service. Nevertheless, it’s still better to create named profiles: this is pleasant for employees and makes it easier for the business to track who has what levels of access to the system. This approach is relevant for both author and publish levels.

Security at the publish level

Typically, it takes a long time for a project team to realize that they haven’t implemented checks for anonymous users. While regular users may have operational limitations, anonymous users often have far greater rights to execute actions.

The Apache Sling Referrer filter is a convenient and effective mechanism for securing your application. For instance, when sending metrics to AEM, you will see the information in the Inbox about the data submission. If you exceed the default value, an external system may send that request. This means that anyone can’t just submit a request. You add the domain to the configuration, and when the request is made, it verifies against the initially stored data. If everything matches, the integration occurs.

With the filter, you can set more flexible configurations: you can specify the request, method, and host. There are also options for an empty value or a wildcard for more detailed requests.

Security at the dispatcher level

Developers encounter the dispatcher in about 10% of cases. This is the main configuration file where we specify the type of URL (blocking/allowing).

Typically, developers create a small task, set a rule, and forget that it can introduce vulnerabilities. To prevent anyone from attempting to attack your instance, it’s crucial to check the URLs with selectors for availability.

Through the configuration file, you can specify how to handle headers. The more accurately you specify the header, method, etc., such detailed settings will ensure nothing gets broken. These are basic examples. But what if there are hundreds of such rules, making navigation through them more complicated?

The simplest method is to enable logging. Depending on the version of Apache, the operational mechanisms may vary slightly. But your system will immediately highlight which URL has which specific rule and what still needs adjustments.

You can also specify domains in the rules, which refers to integration. Since the dispatcher is used for caching, requests are executed much faster: there’s no need to go anywhere for checks, and you can deliver directly to the client. Plus, this method significantly enhances the security of your application.

Cross-site request forgery (CSRF)

The general principle of CSRF: suppose you’re using your account on a bank’s website. After logging in, you have a standard session with cookies in your browser, receive an email, and click on a link to a suspicious site. On this site, the attacker has embedded a form that sends your data to the bank’s website upon filling out.

The issue lies within the HTTP protocol. The attacker doesn’t need much data; this request is sufficient. The bank’s server sees that a request has arrived, and there are cookies and a session, everything appears fine. This is how typical attacks work.

How can AEM help prevent request forgery?

A classic example of protection is generating a «secret» string. When a form is generated, this secret token is added from a hidden field. If you visit the attacker’s site, the system will detect the absence of the token or its invalidity and refuse to send data. Sometimes, protections are also implemented against the users themselves.

Now, you have a typical AJAX request where it’s impossible to add a hidden field. At the authorization stage, the server returns a cookie named CSRF; you pass it in the header and send it to the server. Thus, you’ve signed the request.

AEM will do all of this for you: it will generate keys, tokens, and verify form submissions.

There are cases when applications are built on React and there’s a complicated integration issue. AEM has accounted for this situation: you simply visit the endpoint and sign it for verification. This works well when using non-standard components and libraries.

What else can be done to protect the system:

Utilize libraries that are responsible for this. There’s no point in adding them until something breaks. At a low level, you can review all «secrets.» This acts as a validation check on your data. It’s simple: there’s a ready-made API, and you’re already protected from this type of attack.

DDoS attacks — the second most common attack

The goal is to exhaust the physical capabilities of the server. Millions of requests are made to a particular host. When they become infinite, the system starts to physically struggle. Typically, powerful attacks originate from multiple sources, using VPNs. No one is 100% immune to such attacks, but let’s not make it easier for them.

In what cases is the system vulnerable:

• The system is configured with an incorrect suffix.
• Numerous requests on AVS; the dispatcher on publish can’t forward them.
• When unlimited nodes of content are allowed to be output. Specifically, the JSON renderer can traverse the tree structure across several levels.
• Accessing localhost:4502/.json can dump the entire repository in JSON format.

To make your work in AEM safer, focus on the capabilities of specific users.