Sling Servlet Best Approach | Community
Skip to main content
New Participant
August 19, 2025
Solved

Sling Servlet Best Approach

  • August 19, 2025
  • 2 replies
  • 500 views

Hi everyone,
I have a few path- and resource-based servlets.


For path-based servlets, the URL starts like: http://localhost:4502/bin/test/v1/<identifier> Is exposing /bin to end users considered a problem? If yes, why so, since /bin/test/v1 is not a valid content path in AEM?

In my case, I want to mask /bin/test/v1/<identifier> with a proxy. This proxy will be called from the client side, and I plan to add Apache rewrite rules to map the proxy URL back to the actual servlet. Is this the best way?

 

For resource-based servlets, the URL starts like: http://localhost:4502/content/test/.../<page>.selector.extension I am masking these too with a proxy. Clients will call the proxy, and I’ll redirect it to the servlet API.

My main question: Is writing Apache rewrite rules the best solution here, or would it be better to use something like Sling resource mapping?

 

Thanks in advance!

Best answer by SantoshSai

@matthewda19 

It's not inherently a security risk, but it’s not considered best practice either.

  • With path-based servlets, you lose repository-level access control.

  • With resourceType-based servlets, you can apply auth/authz policies on the resource.

That’s why Adobe generally recommends using resourceType where possible.

If you must stick to path-based:

  • Keep them under /bin/ (not /apps or /libs)

  • Control access via Dispatcher filters or custom filters

  • Only add rewrites if you want to make URLs “prettier” for end users, but don’t rely on rewrites for security


In short:

  • You can expose /bin paths, and technically it will work fine.

  • It’s not best practice, because:

    • You lose repository-level access control.

    • It makes governance harder in multi-tenant or enterprise setups.

  • Preferred approach -> use resourceType-based servlets for most cases.

  • If path-based is required, secure it properly at the Dispatcher and AEM filter level.

  • Use Apache rewrites only if you need nicer/proxy URLs, not as a replacement for proper servlet registration.

References:

2 replies

arunpatidar
New Participant
August 21, 2025

Hi @matthewda19 

You should register your servlet with resourceType.

if you calling the api at clienside then I would suggest to expose the path in metatag and use that.

 

Example

<!-- <meta name="basepath" content="currentPagePath.selector.extension"> --> <meta name="basepath" content="/content/mysite/us/en.api.json">



And you can register your servlet with

@SlingServletResourceTypes(resourceTypes = "cq/Page", methods = HttpConstants.METHOD_GET, selectors = Constants.API_SERVLET_SELECTOR, extensions = Constants.EXTENSION_JSON)

 

Arun Patidar
SantoshSai
New Participant
August 19, 2025

Hi @matthewda19,

Is there a specific reason you’re registering your servlet using path?
If you use a resourceType instead, you won’t need to expose /bin or mask it. You can leverage selectors and extensions directly on content paths.

Docs for reference: https://sling.apache.org/documentation/the-sling-engine/servlets.html

Are you constrained to path-based servlets for some reason?

Santosh Sai
New Participant
August 19, 2025

@santoshsai Thansk for your response!
I can switch some of them to resourceType-based servlets, but for others I still need path-based ones (integration APIs that aren’t tied to content). That’s why I’m worried about exposing /bin and considering masking it behind a proxy. Would exposing /bin directly actually be a problem?

SantoshSai
New Participant
August 19, 2025

@matthewda19 

It's not inherently a security risk, but it’s not considered best practice either.

  • With path-based servlets, you lose repository-level access control.

  • With resourceType-based servlets, you can apply auth/authz policies on the resource.

That’s why Adobe generally recommends using resourceType where possible.

If you must stick to path-based:

  • Keep them under /bin/ (not /apps or /libs)

  • Control access via Dispatcher filters or custom filters

  • Only add rewrites if you want to make URLs “prettier” for end users, but don’t rely on rewrites for security

Santosh Sai