Restricting and allowing HTTP methods in AEM Dispatcher

HTTP methods such as OPTIONS, POST, PUT, and DELETE can be blocked or exposed incorrectly at the Dispatcher tier in AEM. This can break CORS preflight requests, expose Sling POST behavior on Publish, or produce security findings when public endpoints accept unsafe methods. The issue usually comes from legacy Dispatcher rules that block OPTIONS broadly or from missing deny filters that allow unsafe POST requests to reach Publish. Review Dispatcher filters, allow OPTIONS only where required, and block unsafe methods and Sling POST operations explicitly.

Description description

Environment

  • Adobe Experience Manager as a Cloud Service
  • AEM Managed Services
  • Adobe Experience Manager On-Premise

Issue/Symptoms

  • OPTIONS requests are blocked at Dispatcher.
  • POST requests to DAM or .json resources return 200 OK and expose Sling POST operations.
  • PUT or DELETE requests fail only in AEMaaCS Stage or Production with 405 Method Not Allowed.
  • Security scans report exposed methods, such as public pages accepting POST or showing OPTIONS.

Cause

Legacy Dispatcher security rules often block OPTIONS to prevent verb tampering, while missing or overly permissive filters can allow unsafe POST, PUT, or DELETE requests to reach AEM Publish. This can expose Sling POST behavior on public endpoints. In AEM as a Cloud Service Stage and Production, PUT and DELETE can also be blocked intentionally to protect repository integrity.

Resolution resolution

To resolve blocked or exposed HTTP methods at the Dispatcher layer, follow these steps:

  1. Identify which methods are incorrectly allowed or blocked by testing the affected endpoints with OPTIONS, POST, PUT, or DELETE.
  2. Review the Dispatcher filters and update them so safe methods are explicitly allowed and unsafe methods are explicitly denied.
  3. Use filter rules similar to the following examples, and adjust them to match the exact paths and methods required in your environment.
/deny-post { /type "deny" /method "POST" /extension '(css|png|pdf|jpg|js)' }
/deny-operation { /type "deny" /method "POST" /url ".*:operation.*" }
/allow-options-cors { /type "allow" /method "OPTIONS" /url "/graphql*" }
  1. If you use AEM Managed Services or On-Premise, review dispatcher.any and, if needed, restrict methods at Apache HTTPD for paths that should not accept them.
  2. Use Apache HTTPD restrictions similar to the following example where method blocking is required at the web server layer.
<Limit OPTIONS>
Order deny,allow
Deny from all
</Limit>
  1. Apply path-specific rules where only selected methods should be allowed.
/0035 { /type "allow" /method "GET" /url "/libs/granite/security/currentuser.json*" }
/0036 { /type "deny" /method "DELETE" /url "/libs/granite/security/currentuser.json*" }
  1. Allow OPTIONS only on endpoints that require CORS preflight, such as GraphQL or SPA API routes, instead of enabling it broadly.
  2. If Sling POST behavior is exposed on Publish, add a deny rule for operation-based POST requests and place it after broader allow rules so the final match blocks the request.
  3. For AEMaaCS Stage and Production, if PUT or DELETE requests behave unexpectedly after you confirm the Dispatcher configuration, contact Adobe Support.
  4. Retest the affected endpoints and confirm that blocked methods return the expected 403, 404, or 405 responses, while required OPTIONS requests succeed only on intended endpoints.
recommendation-more-help
experience-cloud-kcs-help-kbarticles