Level 2

Solved

AMS Dispatcher denies Options method

Forum|Forum|7 months ago
June 11, 2025
3 replies
1131 views

Hello Community,

In the AMS Dispatcher configuration, OPTIONS requests are denied in the `security.conf` file to mitigate potential attack vectors. I understand this configuration was implemented around five years ago, likely in a response to a vulnerability at the time.

I would like to ask if someone could shed light on the specific vulnerability that this rule was intended to address and if it still persists in modern version of HTTPD. The reason for my inquiry is that we have a use case involving requests with the `Authorization` header. As a result, the browser sends preflight requests, which unfortunately get blocked at the Dispatcher tier due to this rule.

Would it still be considered unsafe to allow such preflight requests, or has the underlying risk been resolved in recent updates to the HTTPD server? Your insights and recommendations would be greatly appreciated.

Thank you in advance,

Rustam

Best answer by ButhpurKiran

Hi,

yes, it is implemented to mitigate Optionsbleed" vulnerability (CVE-2017-9798) ocurred in 2017, https://nvd.nist.gov/vuln/detail/cve-2017-9798 can give more insights on internal of the issue.

Regarding your use case involving requests with the Authorisation header, which trigger preflight OPTIONS requests, it's generally safe to allow such preflight requests. Modern versions of Apache HTTP Server have addressed the Optionsbleed vulnerability, and allowing preflight OPTIONS requests is necessary for proper Cross-Origin Resource Sharing (CORS) functionality.
The updated version of Apache HTTP Server version that includes the patches for CVE-2017-9798 should help mitigate the issue automatically.

Hope this gives info you are looking for.

Thanks,

Kind regards,

Kiran Buthpur

ButhpurKiranAccepted solution

Level 4

Hi,

yes, it is implemented to mitigate Optionsbleed" vulnerability (CVE-2017-9798) ocurred in 2017, https://nvd.nist.gov/vuln/detail/cve-2017-9798 can give more insights on internal of the issue.

Regarding your use case involving requests with the Authorisation header, which trigger preflight OPTIONS requests, it's generally safe to allow such preflight requests. Modern versions of Apache HTTP Server have addressed the Optionsbleed vulnerability, and allowing preflight OPTIONS requests is necessary for proper Cross-Origin Resource Sharing (CORS) functionality.
The updated version of Apache HTTP Server version that includes the patches for CVE-2017-9798 should help mitigate the issue automatically.

Hope this gives info you are looking for.

Thanks,

Kind regards,

Kiran Buthpur

U

user62746Author

Level 2

Hi @buthpurkiran ,

Thank you for the quick response.

After reviewing the OptionsBleed vulnerability, I noticed that according to Apache's documentation, the issue was resolved in version 2.4.28, which was released back in October 2017. However, the `security.conf` file was added in 2019 - 2 years after the vulnerability fix.

This raises question: In 2019, was AMS still running Apache HTTPD version earlier than 2.4.28 or was there another reason to block the Options method?

Thank you for your insights!

Regards,

Rustam

ButhpurKiran

Level 4

Hi,

This Apache version for your environment can be checked in AMS that is in use for your applications.

Enter either

httpd -v or apachectl -v

Alternatively, you can unblock the pre-flight calls with below approach
(PS: Browsers performs OPTIONS calls to check whether it is safe to send cross origin request to server. Please check all the files before making changes, these are for graphql usage generally used for headless(accessing ContentFragments through persisted graphql) implementations. The paths may change according to your project requirements.)

In your Adobe Experience Manager (AEM) Dispatcher configuration, you can modify your filters.any file and Apache's virtual host configuration. This setup ensures that preflight requests are processed correctly without compromising security.

1. Update filters.any in Dispatcher Configuration

Add the following rule to your filters.any file to allow OPTIONS requests for specific paths, such as GraphQL endpoints

/0060 { /type "allow" /method "(POST|OPTIONS)" /url "/content/_cq_graphql/*/endpoint.json" }

/0061 { /type "allow" /method "(GET|POST|OPTIONS)" /url "/graphql/execute.json*" }

These rules permit OPTIONS requests for the specified GraphQL endpoints, which is essential for CORS preflight checks.

2. Configure Apache Virtual Host for CORS

In your Apache virtual host configuration file (e.g., dispatcher/src/conf.d/available_vhosts/<example>.vhost), add the following CORS headers to handle preflight requests.

<VirtualHost *:80>

  ...

  <IfModule mod_headers.c>

    Header always set Access-Control-Allow-Origin "*"

    Header always set Access-Control-Allow-Methods "GET, POST, OPTIONS"

    Header always set Access-Control-Allow-Headers "Authorization, Content-Type, Accept"

    Header always set Access-Control-Max-Age "600"

  </IfModule>

  ...

</VirtualHost>

This configuration allows cross-origin requests from any origin (*), which is suitable for development environments. For production, replace * with specific trusted origins to enhance security.

3. Ensure Authentication Excludes OPTIONS Method

If your server uses Basic Authentication, ensure that OPTIONS requests are excluded from authentication checks. Add the following to your Apache configuration:

<LimitExcept OPTIONS>

  Require valid-user

</LimitExcept>

This directive ensures that OPTIONS requests are not blocked by authentication, which is crucial for preflight requests to succeed.

4. Restart Apache Server

After making these changes, restart your Apache server to apply the new configurations:

sudo systemctl restart apache2

By implementing these configurations, your AEM Dispatcher will correctly handle CORS preflight requests, allowing for secure cross-origin interactions, especially for endpoints like GraphQL.

Thanks,

Kind regards,

Kiran Buthpur

arunpatidar

Community Advisor

Hi @user62746

Could you please check https://stackoverflow.com/questions/41231438/why-is-http-options-request-insecure

To avoid triggering an OPTIONS (preflight) request, you can either use an AJAX request instead of the Fetch API, or implement a proxy pattern—this ensures the browser always sends requests to the same domain, while the CDN or server handles routing to the actual API endpoint.

preflight requests also bad for performance.

Arun Patidar

U

user62746Author

Level 2

Hello @arunpatidar ,

Thank you very much for providing the resource and suggestions.

I will communicate with our Dev team to explore whether switching to an AJAX request is a viable solution. We are considering a proxy setup as a last-resort solution.

While I understand potential risks associated with OPTIONS requests, it's worth noting that browsers still send them quite frequently, and as such, it seems reasonable to consider them legitimate in many cases. Additionally, I couldn't identify any specific security issues tied to handling OPTIONS requests in nginx.

Thank you once again for your assistance and insights, it's been incredicly helpful.

Regards,

Rustam

U

user62746Author

Level 2

Hi @arunpatidar ,

I've communicated with our Dev team, and it turned out that they are already using AJAX requests rather than Fetch. Despite this, browser keeps sending preflight requests.

Regards,

Rustam

U

user62746Author

Level 2

I created an Adobe Support Ticket for this question and here is their response

The dispatcher configuration (in the security.conf file) blocks HTTP OPTIONS requests. This rule was introduced roughly five years ago as a security measure. When the rule was implemented, blocking unsolicited HTTP methods (including OPTIONS) was part of a hardening strategy to reduce the attack surface. In early configurations, techniques such as HTTP verb tampering could have allowed an attacker to probe for available methods or misuse less-common HTTP verbs (such as OPTIONS or TRACE) to gather information about the backend or even bypass specific access controls.

This practice was adopted to minimise risks related to attackers potentially using methods not intended for everyday client use (OPTIONS, PUT, DELETE, etc.) to exploit misconfiguration. If mishandled, OPTIONS requests could potentially reveal backend details or the allowed methods on sensitive endpoints.

Since then, both HTTP server software (like Apache HTTPD) and AEM's dispatcher have evolved. Modern versions include tighter security measures and more granular configurations. In addition, the prevalence of CORS (Cross-Origin Resource Sharing) and its requirements have made it common to allow OPTIONS requests as 'preflight' checks, especially when using custom headers such as an Authorisation header.

Allowing OPTIONS requests is generally safe if your backend is properly secured. With an appropriately tuned dispatcher and strict access controls on AEM, allowing OPTIONS requests for specific endpoints (e.g., those handling CORS and preflight checks) should not introduce undue risk.

Instead of a global allow, adjust your security.conf (or similar dispatcher filter files) to conditionally allow OPTIONS only on the endpoints that need to handle preflight requests. Follow the latest security guidelines provided in Adobe's Dispatcher Configuration documentation. For example, you can reference the Dispatcher Configuration Documentation on Experience League for detailed insights. Ensure that a security review accompanies any changes to guarantee that no additional endpoints or sensitive resources inadvertently become accessible.

The legacy rule protected against historical risks (verb tampering and unwanted method exposure). With modern HTTPD and dispatcher configurations in place - and given that CORS preflight requests are essential for supporting use cases involving custom headers like Authorisation - it is acceptable (and often necessary) to allow OPTIONS on dedicated endpoints. The underlying risk has been mitigated in current versions as long as access is tightly controlled and only applied to the appropriate routes.

ButhpurKiran

Level 4

Clear insights! Thanks for sharing.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded