Latest Posts

Restricting anonymous access to CQ5’s server logs

Accessing server logs from CRXDE lite

CRXDelight has a very handy feature which lets developers access CQ5’s server logs from the interface. You can do so by clicking the “Console” tab, then deselecting the “Disable Console” icon.

Deselect "Disable Console" to view server logs in CRXDelight

Deselect “Disable Console” in the “Console” tab to view server logs in CRXDelight.

The server logs are loaded from the following location:


Accessing the path above unauthenticated will present you with either a 401 (unauthorized) status code, or a login page. However, if you log in as the anonymous user you can view complete server logs.

When logged in as the "anonymous" user, you have access to server logs

The “anonymous” user, is capable of viewing server logs.

Restricting access to server logs

In a publicly accessible CQ environment access to server logs through CRXDelight should be disabled to prevent unwanted users from gaining sensitive server information.

To disable CRXDelight’s server logs it is recommended you disable the Day CRXDE Support ( bundle. To disable the CRXDE support bundle:

  1. navigate to the system console at http://{server}/system/console/bundles
  2. locate the Day CRXDE Support ( bundle
  3. click the stop icon to the right of the bundle

The Day CRXDE Support bundle can be stopped from the system console.

The CRXDE Support bundle can be stopped from the system console.

Disabling the Day CRXDE Support bundle will disable web-based log viewing for all users. After disabling the support bundle a 403 (forbidden) status code will be thrown when attempting to access /bin/crxde/logs.

5 reasons why you should disable CQ5’s built-in feeds

We’ve already talked about the .feed selector before, but there are still a surprising amount of CQ5 developers that don’t know about the built-in web syndication feeds, or how they can be used to snoop through your site. This is reflected in the fact many CQ5 servers still have it enabled.

The .feed selector is comparable to Apache’s directory listing feature:

Apache directory listing

Unless properly disabled, the .feed selector can be used on any node to list the child nodes directly beneath it.

Feed listing from /content/geometrixx/en.feed

There are a few different types of feeds you can get based on selector combinations:

Selector Nodes Returned
{page}.feed All child pages are listed
{page}.feed.xml All nodes are listed, limited to 31 results
{page}.feed.html The same as .feed, but can be used if the web server settings require the URL end in .html

Note: depending on server configuration, you may not be able to click the links in the feed. You may have to manually copy the name of the next node you want a feed of.

5 reasons why you should disable the .feed selector

  1. To protect pages that should not be linked yet. For example: if you have a secret product that’s going to be launched and you want to make sure it looks OK on the production web server. Using the .feed selector you can find the secret page.

    /content/geometrixx/en/products.feed.xml shows the secret page

    Note: ideally you should test top secret unreleased pages on a preview server, not your live environment!
  2. To prevent other sites from being browsed. If you’re hosting more than one domain (eg: /content/site1, /content/site2), and not re-writing /content/ out of the URL then other sites can be discovered and browsed
  3. To prevent /apps/ from being browsed. It’s possible to browse /apps/ with the .feed selector if you’re running a version of CQ older than 5.5, and haven’t successfully blocked /apps/ in your dispatcher file, or are running 5.5 and gave anonymous access to /apps/ (which you should never, ever do).

    1. /apps/geometrixx/components.feed.xml
    2. /apps/geometrixx/components/newsletterpage.feed.xml
    3. /apps/geometrixx/components/newsletterpage/body.jsp

  4. To prevent browsing of user-submitted data in /content/usergenerated/. Using the .feed selector you can browser the user-generated data that’s stored in /content/usergenerated. CQ’s Social Collaboration features write data such as comments (including ones that are unmoderated) and forum posts here.

    1. /content/usergenerated/content.feed.xml
    2. /content/usergenerated/content/geometrixx.feed.xml
    3. /content/usergenerated/content/geometrixx/en.feed.xml
    4. /content/usergenerated/content/geometrixx/en/community.xml

  5. To prevent test pages from being found. Sometimes you need to test pages before making them available. Most times they’re filled with funny looking placeholder content. It’s often easy to find test pages using the .feed selector. Ideally you would test pages like this on a preview server, not your live environment.

    /content/geometrixx/en.feed.xml reveals some test pages

How to disable the .feed selector

Check out 3 important things you (probably) forgot to configure on your CQ instance for how to disable the .feed selector.

If you know of a better way to disable the .feed selector, or have any questions or comments, please let us know in the comments!

Default CQ5 users and passwords

Below is a table of CQ5’s default user/password combinations.

User Default Password Information
admin admin This must be changed in multiple locations
author author This password is reset to the default password in the CQ5.5 upgrade
anonymous anonymous Protecting the “anonymous” account
replication-receiver replication-receiver New to CQ5.5, this user is disabled by default (and is in the administrator’s group) jdoe aparker

Click here to toggle default users with unknown passwords

User password SHA-1 Hash unknown 83c836e9377ff57fb87bd77434060736564dc164 unknown 8d6bf063cc16d310d6ca8f478e6a0913cb33b7bc unknown 600fa439e52469d7aa3402333f6d3d5b2c43cb3e unknown 61cce9f1ed576adbed4bc4548c0f8ebd8b86a0ae unknown 51b35510f0782d6f0f61513bc66c7f4b744a99f1 unknown f9907e1e665bb8da7cf413448ede235a37c45d38 unknown c3aa9acb8a050b13ccb74ea8574459978899a65d unknown 5a071daa2eaeb104dcce21359d88532aa215c409 unknown c77a1a72b97e07d5bb8579b776e8cffad94f43de unknown a45c870959f1c4ece250b154af3e98fd86b2540b unknown 688bc2fa068f963e3b78d78e731519ff7666c8a7 unknown 1a590831674c5f22513920e3d1f8d7b03bc7aa26 unknown d6e056c931a26d58e5c053acac34c5273cbd99e5 unknown f632cf8673fe4ced1873040e0d97073ce415b5e1 unknown 78164bd5282c0184f8668f1350e66d43784a807b unknown 8d74d8ce272c90db8ed0931c5c374dc18f3e0f00 unknown 3e69c0db2e5cd300220002169b64ae429568eea1 unknown cf21c1d26f4e8b0631c8016ac7be17f604fa7f39 unknown 3171f09fb09c98c74ec2bce687599472e3c38300 unknown 1e188aef505c39de31f2f2965a59103ff721bfcf unknown 66e526ab0038204bf2e6482eac6ef5f73b82b990 unknown 5e00564ca7a7f9f646243e6c9dcf01c2be225740

As a best practice, you should remove all of the default Geometrixx users from your servers, and make sure you change the rest of the default passwords.

Please note this list is incomplete! If you’ve found the password for any default accounts that we’ve not listed above, please add it in the comments and we’ll update the tables.

Preventing your source code in /apps/ from being stolen

If you haven’t disabled the XML renderer, which we highly recommend you do, there’s a good chance it’s possible to harvest all of your JSP source code in /apps/ from one url.

This can be done by the following request:


If not properly blocked this will return a full XML listing of everything in your /apps/ directory. This will include the jcr:data nodes of your JSP files, base 64 encoded.

Here is an example of some XML returned:

<newsletterItem.jsp jcr:primaryType="nt:file" jcr:created="2011-08-26T11:35:36.869-03:00" jcr:createdBy="admin">

If you take the value of the jcr:data node and put it in to a base 64 decoder, you will get the following result:

<%@include file="/libs/foundation/global.jsp"%><%
%><%@taglib prefix="cq" uri=""%><%
%><cq:defineObjects /><%
%><sling:defineObjects /><%

String title       = properties.get("./title", "");
String url         ="./url", ""));
String description = properties.get("./description", "");

if (!title.equals("") && !url.equals("")) {
    %><li style="margin-bottom:10px;font-size:12px;color:#222">
        <a style="color:#55891A;text-decoration:none;font-size:12px;" href="<%=url%>"><%=title%></a>
        <% if (!description.equals("")) { %>
            <p style="margin-top:5px"><%=description%></p>
        <% } %>
} else {
    out.println("Please enter a title and URL from the properties dialog.");

It is not sufficient to block access to /apps/ in the dispatcher.any config file because the /apps.xml file is technically above that directory. We recommend you turn off the XML renderer, but you could also add a new rule in the dispatcher.any file to block it:

/0080 { /type "deny" /glob "GET /apps.*" }

Be sure to update 0080 to a number appropriate to your setup.

As always, if you have any questions or comments, let us know in the comments!

Disabling the XML renderer

A default CQ5 install has a handy feature that outputs any page, and the page’s children in XML format. The output contains all of the properties on a page, such as jcr:primaryType, cq:template, jcr:createdBy, jcr:data (base64 encoded), and sling:resourceType.



  jcr:createdBy="admin" jcr:title="Contact" 
  sling:resourceType="geometrixx/components/contentpage" subtitle="mail">
  <par jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/parsys">
      text="<p><b>Geometrixx World Headquarters</b><br> 1234 Wilshire Blvd.<br> Los Angeles, CA 90210<br> 
          USA</p> <p><b>Geometrixx US East Coast</b><br> 10 Avery Street<br> Boston, MA 02111<br> USA</p> 
          <p><b>Geometrixx EMEA</b><br> Barfuesserplatz 6<br> 4051 Basel<br> Switzerland</p> 
          <p><b>Geometrixx APAC</b><br> 14 Temasek Blvd.<br> Singapore</p> <p>&nbsp;</p> " textIsRich="true"/>
  <rightpar jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/iparsys">
    <iparsys_fake_par jcr:primaryType="nt:unstructured" sling:resourceType="foundation/components/iparsys/par"/>

While this feature can be useful to get a quick overview of a page while developing, we recommend that it be disabled on production machines, especially the publish server. Here is a reason why.

Disabling the XML renderer

To disable the XML renderer, navigate to the OSGI configuration manager at the following URL:


Click on Apache Sling GET Servlet, uncheck “Enable XML”, then click save.

Verify that you’ve disabled the XML renderer by trying to view a page on your instance as .xml instead of .html.

Any questions or comments? Let us know!

CRXDespair or Why Is Adobe CQ So Hard?

This post is a overview of some of the architectural problems I have found with Adobe CQ. As a developer with about 15 years of experience and a year and a half working directly with the product I feel I can give some insight in this regard. The following sections deal with key problem areas in turn.

What’s In A Name?

This CMS has undergone a few name changes but none as confusing as currently. Initially called Comuniqué, it rose to prominence as Day software’s CQ. Then, late in 2010, they were purchased by Adobe. Since that time there appears to be confusion from the new owners as to what to call it. CQ 5.4 persists alongside something called WEM (easily confused with ADEP which is apparently the new name for CRX). Nevertheless, at the time of writing, the next beta version of the software is titled CQ 5.5. The real story group have also pointed to this lack of focus. See the following post for more details.

Not All Its Stacked Up To Be

So the merger is a bit bumpy, but what about the underlying technology? Well, about 2005, programmers started to get fed up with the J2EE stack (and Java in general) that CQ is built upon. They started turning to less complicated alternatives like python, ruby and PHP.  Bruce Tate, formerly a Java mavin, documents this pretty well in his book of that time: Beyond Java.

Don’t get me wrong, Java is a fine language. I have worked with it for many years now and retain a fondness for it. However, the direction that Sun took Java as a web application platform became overly complicated. Just look at the 100s of lines you get in a Java web application error stack trace compared with other environments and you start to see what I mean.

I would like to suggest that a simpler set of APIs and some kind of server-side scripting language would alleviate developer stress. Alfresco CMS (another open-source Java based CMS) has had server side JavaScript for a number of years now. There are a number of other Java based scripting options (JRuby, Groovy, etc) that would ease the process of developing components in CQ.

You Ain’t Got a Thing, If You Ain’t Got That Sling

Well, at least its built on something open-source and freely available. Right? Isn’t it using that apache project Sling and Jackrabbit? Yes, that’s true. But who else is using those projects? It is commendable that Day (and now Adobe) release a portion of their code to the world but the criticism of over-complexity is valid here as well. If Sling and Jackrabbit were widely used platforms, they wouldn’t feel so obscure and undocumented to work with.

Furthermore, there exists a strange gap between the open-source side of the product and the propriety modules built upon them. This feels like the gap that exists between the corporate giant of Adobe and its new acquisition. One hand seems to be uncertain as to what the other is doing. For examples of this disconnect, I direct you to other posts on this site.

Further Frustrations

An example that I often find of CQ’s complexity is how you will find an example of how something works (submitting a form for example: shockingly complicated in CQ) and you will try this out only to find that it works fine on the author server but runs into problems when on the publisher. Or you figure out the whole author-publisher tangle and run into a brick wall with the dispatcher cache.

This is another example of how the system has so many moving parts that it seems no-one in the organization is sure how it all hangs together. This is particularly noticeable in the weakness of certain non-core modules: social collab, mobilie, etc. Yes, the author interface for CQ is nice to use and it is a key selling point for the software but once you stray from this functionality, the offering gets very weak.

Another frustration for developers within CQ is the inadequate development environment. I have not used the stand-alone eclipse-based CRXDE in a while because of its memory leaks and instability. I mostly focus on the browser-based CRXDE lite. It more or less works although it has its foibles. Neither option, however, provides proper source code management. For that you have to turn to something called FileVault which gives you file based access. It is a complex and brittle process to keep this in sync with a subversion repository.


This kind of duplication of effort is endemic in CQ. There is never a single place to do things but multiple locations that are slightly different. For example, there are two package managers for packaging code. There are multiple ways to browse and edit the repository tree. I can’t remember how many places you have to set the admin password, but it should not be more than one.

The point of all this is to put a record out there of the challenges developers face within CQ. The hope is that Adobe address these problems. Developing within a CMS platform is difficult. If the vendor of the platform listened to our pains then we really could have CRX delight.


How to protect your CQ instances from Google searches

There are quite a few CQ5 administrators that have a problem they don’t even know about. Believe it or not, it is incredibly easy to find CQ5 author and publish servers with a simple Google search.

By using Google’s inurl: search, and some common CQ5 paths or terms, it doesn’t take much effort to turn up CQ servers that are either not configured properly, or are development machines.

Here is an example search that lists servers that have not removed Geometrixx:

Using other common CQ paths will turn up many, many more servers. Using system URLs, such as the login page, will usually result in only author or publish servers showing up in the search results.

First and foremost, as a best practice, we’d recommend all of your CQ5 author and publish servers be put behind a firewall, not publicly accessible. Only your web server (dispatcher) should be in front of the firewall. If your author and publish servers are behind a firewall, there won’t be any way for Google to index them.

If it is absolutely necessary for your author or publish server to be in front of a firewall, you should add a robots.txt file to the root directory /. This file will prevent most search engines from displaying your server in search results. Here are the steps for doing this:

  1. Navigate to CRXDelight at {server}/crx/de/ (Make sure you’re logged in as admin)
  2. Right click on your root node, and go to Create … > Create File …
  3. Name the file robots.txt
  4. Place the following code in the file, and save it:
    User-agent: *
    Disallow: /
  5. Now we have to grant the anonymous user read access to the file. To do this, navigate to the user admin section at {server}/useradmin
  6. Open the anonymous user, and click on the permissions tab
  7. Grant read access to the robots.txt file, then click save
  8. Verify the robots.txt file exists and is accessible by first logging out, then navigating to {server}/robots.txt
  9. If it’s there, search engines should no longer index your server
  10. Repeat these actions for all author/publish servers that are publicly accessible.

Additionally, it’s a good idea not to distribute your author or publish URLs in publicly accessible web locations.

Have any other methods of protecting your author and publish servers from searches? Please let us know in the comments!

3 important things you (probably) forgot to configure on your CQ instance

Let’s face it… setting up a full-fledged CQ5 environment is no picnic. A typical production system will have at least 5 servers (one author, two publish, two web servers). Add a 5 server staging setup, a 3 server development setup, a 3 server preview setup, and you’re looking at a ton of CQ instances to manage.

Here are a few common configuration items many people overlook when setting up their CQ5 environment.

  1. Change default passwords. This really sounds like a no-brainer, but you’d be surprised how many people forget to change one of the default passwords. There are quite a few passwords that have to be changed, here’s the list:
    • 3 admin passwords
      1. admin user account
      2. /system/console (Apache Felix Web Management Console) admin password
      3. /admin (CQSE) admin account
    • “author” user account

    You should also delete the default Geometrixx users.

  2. Disable the JSON query selector. CQ comes with a handy query tool built in. Using the query.json selector you can run arbitrary XPATH queries on the server. This could include a query that accesses the entire repository, which could slow your system down considerably, or even cause a denial of service if run multiple times.

    Here are some example queries:

    This XPATH statement will query all nodes in the repository, putting excessive load on the server.

    This query will look for any passwords stored in a “pass” property.

    http://localhost:4502/content.query.json?statement=//*[@transportPassword]]/(@transportUser | @transportPassword)
    This query will return the transport user (typically admin), along with DES encrypted password.

    One method of disabling this is to add the following entry to your dispatcher.any file(s):

    /0080 { /type "deny" /glob "GET *.query*" }

    Make sure to update 0080 to a number appropriate to your config. Also, please note that this means you’ll not be able to use any of your own selectors that start with “query”.

    Note: This JSON query tool is disabled by default in CQ5.5.

  3. Disable “feed” listing. Another little known CQ5 gem is its out of the box directory-listing like selector. Using a combination of {page}.feed.xml, or {page}.feed.html you can get a listing of pages underneath the current node.

    This could be used to navigate your tree, and locate pages that are not for public consumption, such as test pages. The following example will give a listing of nodes under /content/:


    Depending on your server setup, you may not be able to click on the links in the listing, and you may have to manually add the next folder you want to drill down to in the URL. This next example will list nodes under /apps/geometrixx/


    To disable this, you can add the following entry to your dispatcher.any file(s):

    /0080 { /type "deny" /glob "GET *.feed*" }

    Be sure to update 0080 to a number appropriate to your setup. Also, please note that this means you’ll not be able to use any of your own selectors that start with “feed”.

Have any other common configuration omissions? Know of a better way to lock down the issues mentioned in this post? Please let us know, or leave a comment!

So many selectors

One lesser publicized “feature” of CQ5 is the ability to natively use as many unrecognized selectors as you want in a URL.

This means the following URLs will work:

These examples aren’t that bad, but it’s not hard to think of the possibilities someone could come up with.

The biggest difference between using selectors in a link, and using parameters in a link (ie: ?param=anything_I_want) is selectors make it look much more like an official URL to the user.

But that is not the worst part. Every single different selector combination used will create a new page in the dispatcher cache. This means that theoretically someone could programmatically fill your web-server dispatcher cache until it runs out of hard-drive space.

This should be enough information to have you concerned about the issue. Adobe’s official response is documented on the security checklist under Preventing Denial of Service (DoS) Attacks:

Source: (2012/01/29)

The following code could be used to limit what selectors can be used (the isValidSelector method would have to be implemented):

String[] currentSelectors = slingRequest.getRequestPathInfo().getSelectors();
for (int i=0;i<currentSelectors.length;i++) {
	if(!isValidSelector(currentSelectors[i])) {

The issue with the above code is it will block all selectors you don’t specify as valid in the isValidSelector method. This could lead to some unexpected results, as you’ll be blocking the CQ5 system selectors. In order to make a good isValidSelector method, you would need to know all of the system selectors used by CQ5. Does anyone know where to obtain this list?

Are there any developers out there who have attempted to tackle this issue? Have any thoughts on it? Please leave a comment below!

CQ5’s hidden public proxy server

An out of the box CQ5.4 instance comes with a handy copy of the Apache Shindig proxy. It’s accessible from the following location:


This example would bring you to the site through the shindig proxy in CQ.

A stealthy update to the CQ5 Security Checklist added the following information to the dispatcher restrictions section which tells you to block it:

Source: (2012/01/29)

Make sure you follow their advice, and disable the proxy server in the dispatcher.any /filter section. If left open, it could be used for any number of malicious activities, including gaining access to pages behind your firewall.