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
OPTIONSrequests are blocked at Dispatcher.POSTrequests to DAM or.jsonresources return200 OKand expose Sling POST operations.PUTorDELETErequests fail only in AEMaaCS Stage or Production with405 Method Not Allowed.- Security scans report exposed methods, such as public pages accepting
POSTor showingOPTIONS.
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:
- Identify which methods are incorrectly allowed or blocked by testing the affected endpoints with
OPTIONS,POST,PUT, orDELETE. - Review the Dispatcher filters and update them so safe methods are explicitly allowed and unsafe methods are explicitly denied.
- 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*" }
- If you use AEM Managed Services or On-Premise, review
dispatcher.anyand, if needed, restrict methods at Apache HTTPD for paths that should not accept them. - 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>
- 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*" }
- Allow
OPTIONSonly on endpoints that require CORS preflight, such as GraphQL or SPA API routes, instead of enabling it broadly. - If Sling POST behavior is exposed on Publish, add a deny rule for operation-based
POSTrequests and place it after broader allow rules so the final match blocks the request. - For AEMaaCS Stage and Production, if
PUTorDELETErequests behave unexpectedly after you confirm the Dispatcher configuration, contact Adobe Support. - Retest the affected endpoints and confirm that blocked methods return the expected
403,404, or405responses, while requiredOPTIONSrequests succeed only on intended endpoints.