The dispatcher as a front end system offers an extra layer of security to your Adobe Experience Manager infrastructure. Adobe strongly recommends that you complete the following checklist before going on production.
The Dispatcher Security Checklist
You must also complete the Security Checklist of your version of AEM before going live. Please refer to the corresponding Adobe Experience Manager documentation.
You should install the latest available version that is available for your platform. You should upgrade your Dispatcher instance to use the latest version to take advantage of product and security enhancements. See Installing Dispatcher.
You can check the current version of your dispatcher installation by looking at the dispatcher log file.
[Thu Apr 30 17:30:49 2015] [I] [23171(140735307338496)] Dispatcher initialized (build 4.1.9)
To find the log file, inspect the dispatcher configuration in your httpd.conf.
Adobe recommends that you limit the clients that can flush your cache.
Adobe recommends to enable HTTPS transport layer on both author and publish instances.
When configuring the Dispatcher you should restrict external access as much as possible. See Example /filter Section in the Dispatcher documentation.
Make sure you use filters to block external access to any administrative URLs, such as the Web Console.
See Testing Dispatcher Security for a list of URLs that need to be blocked.
Whitelists are a better way of providing access control since inherently, they assume that all access requests should be denied unless they are explicitly part of the whitelist. This model provides more restrictive control over new requests that might not have been reviewed yet or taken into consideration during a certain configuration stage.
When configuring the Dispatcher you should ensure that the web server is ran by a dedicated user with least privileges. It is recommended to only grant write acess to the dispatcher cache folder.
Additionnaly, IIS users need to configure their website as follows:
In the physical path setting for your web site, select Connect as specific user.
Set the user.
A denial of service (DoS) attack is an attempt to make a computer resource unavailable to its intended users.
At the dispatcher level, there are two methods of configuring to prevent DoS attacks:
- Use the mod_rewrite module (for example, Apache 2.2) to perform URL validations (if the URL pattern rules are not too complex).
- Prevent the dispatcher from caching URLs with spurious extensions by using filters.
For example, change the caching rules to limit caching to the expected mime types, such as:
To safely enable full functionality on the publish instances, configure filters to prevent access to the following nodes:
Then, configure filters to allow access to the following node paths:
- /libs/cq/personalization/* (JS, CSS and JSON)
- /libs/cq/security/userinfo.json (CQ user information)
- /libs/granite/security/currentuser.json (data must not be cached)
- /libs/cq/i18n/* (Internalization)
AEM provides a framework aimed at preventing Cross-Site Request Forgery attacks. In order to properly make use of this framework, you need to whitelist CSRF token support in the dispatcher. You can do this by:
- Creating a filter to allow the /libs/granite/csrf/token.json path;
- Creating a filter to allow the CSRF-Token header.
To prevent clickjacking we recommend that you configure your webserver to provide the X-FRAME-OPTIONS HTTP header set to SAMEORIGIN.
For more information on clickjacking please see the OWASP site.
Adobe strongly recommends to perform a penetration test of your AEM infrastructure before going on production.