Dispatcher Security - .feed extension | Community
Skip to main content
BrettBirschbach
Adobe Champion
BrettBirschbachAdobe Champion
Adobe Champion
July 30, 2019
Solved

Dispatcher Security - .feed extension

  • July 30, 2019
  • 4 replies
  • 5015 views

Reference Adobe Docs at: Configuring Dispatcher

AEM docs have a rule that “prevents content grabbing” where the feed selector is prevented for extensions json, xml, and html.

# Deny content grabbing for /content and its subtree
/0082 {
 /type "deny"
 /path "/content/*"
 /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'
 /extension '(json|xml|html)'
}

Docs also indicate that the following URLs should all be blocked by your configuration:

/content/add_valid_path_to_a_page/_jcr_content.feed
/content/add_valid_path_to_a_page/jcr:content.feed
/content/add_valid_path_to_a_page/pagename._jcr_content.feed
/content/add_valid_path_to_a_page/pagename.jcr:content.feed

However, dispatcher configs for content grabbing are not blocking those URLs b/c .feed is the extension. Adding to the confusion, it seems that all of the following page URLs return the same thing:

- /en.feed.html (blocked by dispatcher rule)
- /en.feed (allowed by dispatcher rule)
- /en._jcr_content.feed (allowed by dispatcher rule)

Adobe dispatcher rule blocks the selector, but not the extension, even though both return the exact same thing.  I'm also curious about the `_jcr_content` / `jcr:content` selector to understand what that triggers and if that should be blocked.

Can someone help me make heads/tails about what should be blocked and what shouldnt be blocked?

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by AndySh4

    It's good to harden the dispatcher to block content grabbing requests because they can expose the architecture of your site and overload your server. Without this kind of hardening at your dispatcher, a crafted request could fetch all your content or expose your source code. The .feed extension can expose areas of your site you might want hidden so it's good to just block it. Blocking _jcr_content or jcr:content is more of a judgement call that depends on how your site works. For example, you might have a component that performs an AJAX request for resources located beneath a page's jcr:content node, so in that case you wouldn't want to block those requests. Below are some selectors it would be wise to block with your dispatcher:

    .blubber.

    .blueprint.

    .docview.

    .feed.

    .infinity.

    .languages.

    .pages.

    .query.

    .rss.

    .scaffolding.

    .sitemap.

    .sysview.

    .tidy.

    .wfsummary.

    4 replies

    A
    AndySh4Accepted solution
    Level 3
    July 31, 2019

    It's good to harden the dispatcher to block content grabbing requests because they can expose the architecture of your site and overload your server. Without this kind of hardening at your dispatcher, a crafted request could fetch all your content or expose your source code. The .feed extension can expose areas of your site you might want hidden so it's good to just block it. Blocking _jcr_content or jcr:content is more of a judgement call that depends on how your site works. For example, you might have a component that performs an AJAX request for resources located beneath a page's jcr:content node, so in that case you wouldn't want to block those requests. Below are some selectors it would be wise to block with your dispatcher:

    .blubber.

    .blueprint.

    .docview.

    .feed.

    .infinity.

    .languages.

    .pages.

    .query.

    .rss.

    .scaffolding.

    .sitemap.

    .sysview.

    .tidy.

    .wfsummary.

      BrettBirschbach
      Adobe Champion
      BrettBirschbachAdobe ChampionAuthor
      Adobe Champion
      July 31, 2019

      Thanks @andyshreve I completely agree with you on the point about blocking content grabbing.  My confusion is that the rule that Adobe docs provide is insufficient to do so.  There are some selectors you have above that are not covered by it.  And though the rule blocks the .feed. selector, it does not block the .feed extension which appears to return the same thing.  Thoughts?

      Also, any idea what the `_jcr_content` / `jcr:content` selector actually does?  I know you can put those tokens in a path to fetch the content node or its children directly, but never seen it in the selector portion of the URL.

      A
      AndySh4
      Level 3
      July 31, 2019

      Documentation should serve as a starting point even though it can be incorrect or incomplete. Sample code provided online is rarely production-ready, and in this case you'll want to write a deny configuration for the feed extension. The documentation lists paths that should be blocked, so you may need to write configuration to block those at a minimum. The other selectors I listed that aren't documented were Adobe ones I've seen over the last 7 years which may or may not still be supported. I haven't seen _jcr_content or jcr:content used as selectors, so maybe someone from Adobe can speak to that.

      joerghoh
      Adobe Employee
      joerghohAdobe Employee
      Adobe Employee
      July 31, 2019

      Please report the missing selectors to Adobe support, so the documentation can be augmented. Thanks!

        Terms & ConditionsAccessibility statement

        Loading footer...