This section deals with various steps that you should take to ensure that your AEM installation is secure when deployed. The checklist is meant to be applied from top to bottom.
There are some additional security considerations applicable at the development phase.
For more information, see Running AEM in Production Ready Mode.
Enabling the HTTPS transport layer on both author and publish instances is mandatory for having a secure instance.
See the Enabling HTTP Over SSL section for more information.
Ensure that you have installed the latest Security Hotfixes provided by Adobe.
Adobe strongly recommends that after installation you change the password for the privileged AEM
admin accounts (on all instances).
These accounts include:
Once you have changed the password for the AEM admin account, you will need to use the new password when accessing CRX.
admin password for the OSGi Web console
This change will also be applied to the admin account used for accessing the Web console, so you will need to use the same password when accessing that.
These two accounts use separate credentials and having distinct, strong password for each is vital to a secure deployment.
The password for the AEM admin account can be changed via the Granite Operations - Users console.
Here you can edit the
admin account and change the password.
Changing the admin account also changes the OSGi web console account. After changing the admin account, you should then change the OSGi account to something different.
Aside from the AEM
admin account, failing to change the default password for the OSGi web console password can lead to:
For more information on changing the web console password, see Changing the OSGi web console admin password below.
You must also change the password used for accessing the Web console. This is done by configuring the following properties of the Apache Felix OSGi Management Console:
User Name and Password, the credentials for accessing the Apache Felix Web Management Console itself.
The password must be changed after the initial installation to ensure the security of your instance.
To do this:
Navigate to the web console at
Navigate to** Apache Felix OSGi Management Console** and change the user name and password.
Adobe recommends to define custom error handler pages, especially for 404 and 500 HTTP Response codes in order to prevent information disclosure.
See How can I create custom scripts or error handlers knowledge base article for more details.
AEM Dispatcher is a critical piece of your infrastructure. Adobe strongly recommend that you complete the dispatcher security checklist.
Using the Dispatcher you must disable the “.form” selector.
A standard installation of AEM specifies
admin as the user for transport credentials within the default replication agents. Also, the admin user is used to source the replication on the author system.
For security considerations, both should be changed to reflect the particular use case at hand, with the following two aspects in mind:
The transport user should not be the admin user. Rather, set up a user on the publish system that has only access rights to the relevant portions of the publish system and use that user’s credentials for the transport.
You can start from the bundled replication-receiver user and configure this user’s access rights to match your situation
The replication user or Agent User Id should also not be the admin user, but a user who can only see content that is supposed to be replicated. The replication user is used to collect the content to be replicated on the author system before it is sent to the publisher.
AEM 6 introduces the new Operations Dashboard, aimed at aiding system operators troubleshoot problems and monitor the health of an instance.
The dashboard also comes with a collection of security health checks. It is recommended you check the status of all the security health checks before going live with your production instance. For more information, consult the Operations Dashboard documentation.
All example content and users (e.g. the Geometrixx project and its components) should be uninstalled and deleted completely on a productive system before making it publicly accessible.
The sample We.Retail applications are removed if this instance is running in Production Ready Mode. If, for any reason, this is not the case, you can uninstall the sample content by going to Package Manager, then serarching for and uninstalling all We.Retail packages. Fore more info, see How to Work With Packages.
These development OSGi bundles should be uninstalled on both author and publish productive systems before making them accessible.
The AEM Developer Tools for Eclipse deployes the Apache Sling Tooling Support Install (org.apache.sling.tooling.support.install).
This OSGi bundle should be uninstalled on both author and publish productive systems before making them accessible.
AEM 6.1 ships with a mechanism that helps protect agains Cross-Site Request Forgery attacks, called the CSRF Protection Framework. For more information on how to use it, consult the documentation.
To address known security issues with Cross-Site Request Forgery (CSRF) in CRX WebDAV and Apache Sling you need to add configurations for the Referrer filter in order to use it.
The referrer filter service is an OSGi service that allows you to configure:
which http methods should be filtered
whether an empty referrer header is allowed
and a list of servers to be allowed in addition to the server host.
By default, all variations of localhost and the current host names the server is bound to are in the list.
To configure the referrer filter service:
Open the Apache Felix console (Configurations) at:
In the Configurations menu, select:
Apache Sling Referrer Filter
Allow Hosts field, enter all hosts that are allowed as a referrer. Each entry needs to be of the form
https://allowed.server:80allows all requests from this server with the given port.
0as the port number.
Allow Empty field, if you want to allow empty/missing referrer headers.
It is recommended to provide a referrer while using commandline tools such as
cURL instead of allowing an empty value as it might expose your system to CSRF attacks.
Edit the methods this filter should use for checks with the
Filter Methods field.
Click Save to save your changes.
Some OSGI settings are set by default to allow easier debugging of the application. These need to be changed on your publish and author productive instances to avoid internal information leaking to the public.
All of the below settings with the exception of The Day CQ WCM Debug Filter are automatically covered by the Production Ready Mode. Because of this, we recommend reviewing all the settings before deploying your instance in a productive environment.
For each of the following services the specified settings need to be changed:
For further details see OSGi Configuration Settings.
When working with AEM there are several methods of managing the configuration settings for such services; see Configuring OSGi for more details and the recommended practices.
A denial of service (DoS) attack is an attempt to make a computer resource unavailable to its intended users. This is often done by overloading the resource; for example:
With a flood of requests from an external source.
With a request for more information than the system can successfully deliver.
For example, a JSON representation of the entire repository.
By requesting a content page with an unlimited number of URLs, The URL can include a handle, some selectors, an extension, and a suffix - any of which can be modified.
.../en.html can also be requested as:
All valid variations (e.g. return a
200 response and are configured to be cached) will be cached by the dispatcher, eventually leading to a full file system and no service for further requests.
There are many points of configuration for preventing such attacks, here we only discuss those directly related to AEM.
Configuring Sling to Prevent DoS
Sling is content-centric. This means that processing is focused on the content as each (HTTP) request is mapped onto content in the form of a JCR resource (a repository node):
This is covered in more detail under Sling Request Processing.
This approach makes Sling very powerful and very flexible, but as always it is the flexibility that needs to be carefully managed.
To help prevent DoS misuse you can:
Incorporate controls at the application level; due to the number of variations possible a default configuration is not feasible.
In your application you should:
404for all others.
Check the configuration of the default renderers, which can be a problem area.
In particular the JSON renderer which can transverse the tree structure over multiple levels.
For example, the request:
could dump the whole repository in a JSON representation. This would cause significant server problems. For this reason Sling sets a limit on the number of maximum results. To limit the depth of the JSON rendering you can set the value for:
JSON Max results (
in the configuration for the Apache Sling GET Servlet. When this limit is exceeded the rendering will be collapsed. The default value for Sling within AEM is
As a preventive measure disable the other default renderers (HTML, plain text, XML). Again by configuring the Apache Sling GET Servlet.
Do not disable the JSON renderer, this is required for the normal operation of AEM.
Use a firewall to filter access to your instance.
Mitigate Against DoS Caused by Using Form Selectors
This mitigation should be performed only on AEM environments that are not using Forms.
Since AEM does not provide out of the box indexes for the
FormChooserServlet, using form selectors in queries will trigger a costly repository traversal, usually grinding the AEM instance to a halt. Form selectors can be detected by the presence of the *.form.* string in queries.
In order to mitigate this, please follow the below steps:
Go to the Web Console by pointing your browser to https://<serveraddress>:<serverport>/system/console/configMgr
Search for Day CQ WCM Form Chooser Servlet
After you click on the entry, disable the Advanced Search Require in the following window.
Mitigate Against DoS Caused by Asset Download Servlet
The default Asset Download Servlet in AEM allows authenticated users to issue arbitrarily-large, concurrent download requests for creating ZIP files of assets visible to them that can overload the server and/or network.
To mitigate potential DoS risks caused by this feature,
AssetDownloadServlet OSGi component is disabled by default for publish instances on latest AEM versions.
If your setup requires that the Asset Download Server be enabled, please see this article for more information.
WebDAV should be disabled on both the author and publish environments. This can be done by stopping the appropriate OSGi bundles.
Connect to the Felix Management Console running on:
In the list of bundles, find the bundle named:
Apache Sling Simple WebDAV Access to repositories (org.apache.sling.jcr.webdav)
Click the stop button (in the Actions column) to stop this bundle.
Again in the list of bundles, find the bundle named:
Apache Sling DavEx Access to repositories (org.apache.sling.jcr.davex)
Click the stop button to stop this bundle.
A restart of AEM is not required.
It is important you protect your users by making sure that you do not expose any personally indetifiable information in the repository users home path.
Since AEM 6.1, the way user (also known as authorizable) ID node names are stored is changed with a new implementation of the
AuthorizableNodeName interface. The new interface will no longer expose the user ID in the node name, but will generate a random name instead.
No configuration needs to be performed in order to enable it, as this is now the default way of generating authorizable IDs in AEM.
Although not recommended, you can disable it in case you need the old implementation for backwards compatibility with your exsiting applications. In order to do this, you need to:
Go to the Web Console and remove the** org.apache.jackrabbit.oak.security.user.RandomAuthorizableNodeName** entry from property requiredServicePids in Apache Jackrabbit Oak SecurityProvider.
You can also find the Oak Security Provider by looking for the org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration PID in the OSGi configurations.
Delete the Apache Jackrabbit Oak Random Authorizable Node Name OSGi configuration from the Web Console.
For easier lookup, note that the PID for this configuration is org.apache.jackrabbit.oak.security.user.RandomAuthorizableNodeName.
For more information, see the Oak documentation on Authorizable Node Name Generation.
To prevent clickjacking we recommend that you configure your webserver to provide the
X-FRAME-OPTIONS HTTP header set to
Certain AEM features and authentication schemes require that you replicate your encryption keys across all AEM instances.
Before you do this, please take note that key replication is done differently between versions because the way in which keys are stored is different between 6.3 and older versions.
See below for more information.
Whereas in older versions the replication keys were stored in the repository, beginning with AEM 6.3 they are stored on the filesystem.
Therefore, in order to replicate your keys across instances you need to copy them from the source instance to the target instances’ location on the filesystem.
More specifically, you need to:
Access the AEM instance, typically an author instance, that contains the key material to copy;
Locate the com.adobe.granite.crypto.file bundle in the local file system. For example, under this path:
bundle.info file inside each folder will identify the bundle name.
Navigate to the data folder. For example:
Copy the HMAC and master files.
Then, go to the target instance you want to duplicate the HMAC key to, and navigate to the data folder. For example:
Paste the two files you previously copied.
Refresh the Crypto Bundle if the target instance is already running.
Repeat the above steps for all instances you want to replicate the key to.
You can revert to the pre 6.3 method of storing keys by adding the below parameter when you first install AEM:
In AEM 6.2 and older versions, the keys are stored in the repository under the
The recommended way to securely replicate the keys across your instances is to only replicate this node. You can selectively replicate nodes via CRXDE Lite:
Adobe strongly recommends to perform a penetration test of your AEM infrastructure before going on production.
It is critical that new development are following the Security Best Practices to ensure your AEM environement stays safe.