Tag Archives: Adobe AEM

AEM Security: How to secure the AEM application?


There is a set security practice followed by every development team in Adobe experience manager ( i.e AEM) CMS technology. And, Most of these are pretty straightforward suggested by the Adobe as best practices however there are many other security issues which have equal importance.

So, Let’s begin to know how to secure your application by putting right rules in your AEM environment.

All other recommendations from the open web application security project(i.e OWASP) should be applied. Below recommendations are very specific to AEM technology & AEM infrastructure.

There are many problems which are unknown to the AEM Solution provider & putting the whole thing at risk. I would like to state one of the examples here to showcase the security problems in AEM.

Use below Google Query to find out if your author instance is indexed by the google or not. I have used a very basic query in google. Try it, you would surprise to see how many author instances which are open to exploits. You might be wondering how to login in those authors. That is fairly easy once you know who has authored the pages.

Google Query: inurl:aemauthor

AEM Author Security:

First & foremost, Make sure your AEM author instance isn’t searchable by the search engine & It is not accessible outside of Intranet without VPN. Follow some author security guidelines below:

  • Keep robots.txt for all your domains including the authoring environment. make sure Google does not index author domain.
  • Enable HTTPS in AEM Author.
  • Changing Admin password in every AEM instance (i.e server).
  • Create groups for assigning access & follow the least privilege principle. Basically, Instead of denying on many hierarchies just allow what individual group needs.
  • Create a separate replication user to use in replication agent configuration. Admin should not be used for replicating anywhere.
  • Limit the number of users in admin groups.
  • Web dev, CRX explorer & CRXDE in prod author should be disabled or should be limited to certain users.

AEM Publish Security

Same as AEM author, publish instances should not be accessible to an outside of the intranet & connections to web servers, author etc should be internal connections. The most important thing to handle in publish security is to handle requests inputs & use proper request sessions. Serving requests with admin session or privileged user is a big problem. 

Assume some data you have to read & anonymous user does not have permission to that then avoid using admin session. Have a dedicated user for that to read/write the content for certain requests. Follow other guidelines respect with AEM Publish security:

  • Anonymous permissions should be checked & make sure not every directory accessible to the anonymous user. Even in etc design, There should be proper permission setup in cloud services etc.
  • Apache Sling Referrer Filter must be configured to handle unwanted publish requests.
  • The cross-site forgery framework should be enabled to filter requests.
  • All default tools (Crx explorer, Crxde, WebDev) etc should be disabled.
  • No one should be able to access publish server directly. Also should not be able to install packages directly.

Dispatcher security

When anyone thinks of AEM security, most of us just think of rules & filters in dispatcher.any configuration file. But, There are many more use cases where things are not pretty if you have not taken care of security:

  • Do not have dispatcher flush agent configured from AEM author. And if it is enabled then have https call for flushing cache. Otherwise, author flush agent exposes to your web server IP & credentials.
  • Limit the request headers information. Request headers are passed in every request to AEM publish based on dispatcher configuration.
  • Do not allow cross-origin requests. Set the SAME origin header at the web server level.
  • Proper input validation should be done in POST Requests & dispatcher filter should allow only certain POST requests.
  • Caching of selectors & URL extensions should be defined. Not every selector or extension should be cacheable. DOS or DDOS attacks are very easy to do in AEM application.
  • Website URL’s should not expose internal directories.

Final thought

We have to secure the infrastructure & security of important environments. Once you have security author, publish & proper dispatcher configuration, you would have a better chance to protect your application. Application security is another aspect follow the below links for Adobe recommendation.


AEM Solution: How to override third-party OSGI Config in AEM


An overriding concept is a pretty known subject in AEM. Components can be overridden in an application with sling resolution technique. Similarly, Apache sling has a resolution order to resolve OSGi configs as well. Basically, application specific config’s can override AEM Libs configs. For more details on OSGI config & their resolution order, Read my posts here.


Let’s consider a scenario of a project where you have to use another AEM Project or third-party source code like ACS Commons. And, There are some services which you want to use but with different configuration. Assume services do have configurations in place.

Now you might be thinking that what is the big deal in that. We can upload third-party code & change the configuration. Well, That is the whole point. The moment you change the configuration for your application, One more maintenance issue happens. Got it? No?

No worry. The issue is that every time you update/install third-party code for your application, You have to manually change the configuration. You might think it is okay. But it is not when you have to support the same in every environment after every deployment. Someone has to fix every time. And what if the configuration has to be updated in prod publish environment. It is tough to maintain. Let me explain with config files.

#Thirdparty config’s XML File match for ContentFeed service under config.publish folder & apps folder is /apps/abc/thirdparty/. ContentFeed Service is part of platform code base.

#Base config: com.abc.core.contentFeed.xml
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"

#Your application would like to override this config. And apps is /apps/myapp etc.

#Brand specific config: com.abc.core.contentFeed.xml

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"

Now, ContentFeed service does not pick your application-specific config & even though you have the same config in your application. It always picks up the third party config. And it happens ContentFeed service is part of platform source code.  I hope the problem is clear to you now. let’s see a solution.

General Solution

A general approach is to keep modifying third-party configs in every environment after each deployment. And, When QA reports this or that not working, a new person struggle to find why it is not working. Most of us do not remember that service configs are overridden by the deployment. The second approach is to override the full code itself with different service name & configurations. Must easy to maintain but having duplicate code & same bugs as third-party has. And fixing bugs every time something fixed in the third-party source.

Alternative Solution

Solution to above problem is simple. Make sure your app config file name is the same as third-party config. Read about XML config & service naming convention. AEM OSGi Config Resolution Order

To make sure Service picks your configuration, You need to create the same XML config under the same run mode folder & with additional run mode info because that is how AEM put precedence over other config’s. Let me explain with source code.

#Third-Party config file name is com.abc.core.contentFeed.xml
folder structure is: /apps/third-party/config.publish, config.author etc.

#Your app config name must be com.abc.core.contentFeed.xml
your Folder structure for config must be: /apps/third-party/config.publish.qa, /apps/third-party/config.publish.stage etc.

I hope the solution is clear to you. Solution seems easy but it solves general problem. Leave a comment if you have any question or feedback. thanks in advance.

AEM Solution: How does an AEM OSGi Config work?


In this post, would like to explain to the readers about how does an OSGi (i.e Open service gateway interface) Config work? Would like to clarify some doubts in this post.

What is AEM OSGi Config?

AEM OSGi config is a mechanism to maintain configurations which are bound to change & varies based on different scenarios. Like loading same config file with QA, Stage & Prod with different entries. OSGi configs are available within the OSGi runtime environment so those can be used by any other service at any time with help of OSGi service registry model. 

How to use OSGi Configs?

To use OSGi Config in your OSGi based application like AEM (i.e Adobe experience manager). Just have an XML File & bind configuration entries (i.e XML file) with Java service or component registered in the OSGi framework.  Here is the AEM example. See a simple XML file  & relative OSGi service.

# OSGi XML File naming convention


#XML File Content in source code.

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
package com.osgiConfig.example;
public class OsgiConfigExample implements SlingSafeMethodsServlet {
   @Property(label = "service path",value = "exmple.com")
   private static final String SERVICE_PATH = "servicePath";
   public void doGet(SlingHttpServletRequest req, SlingHttpServletResponse res) 
   {// your code goes here ...}

How these configs are resolved?

The following order of precedence is used:

  • Repository nodes under /apps/*/config….either with type sling:OsgiConfig or property files.
  • Repository nodes with type sling:OsgiConfig under /libs/*/config…. (out-of-the-box definitions).
  • Any .config files from <cq-installation-dir>/crx-quickstart/launchpad/config/…. on the local file system.

Is Naming convention of XML File necessary?

Yes. Your xml file must follow name convention and that is package name & service class name where the properties annotations are.

Do you really need XML File in our source code?

Yes. OSGi config files must be maintained & put in run mode config folders in your source code. Like config, config.author, config.author.QA etc. If those are not maintained that way, you need to open OSGi config from OSGi admin console & change the config. It becomes more difficult when you have to do the same in the production environment.

Is it really need to have property annotation at the class level?

This question is important because most of us think that if we have OSGi config XML in run mode & it matches the service package name & class then required configuration would be available to use. However, that is not the case. Property annotation gets resolved when an OSGi service/component becomes active in OSGi runtime environment. And OSGi service resolves these properties at the service level. So if you do not have these properties at the service level then Service or component do not load OSGI config’s from your run mode.

Final Thought

Here I tried to put some of the questions & their answers. But still there could be some questions which are not listed here. You can post in comment & I will get back to you.