APIM Cors OPTIONS request 500 error

Hi Ivo Bathke, Thanks for sharing your query with the Microsoft Q&A community.

I understand you’re seeing a 500 Internal Server Error on the OPTIONS (CORS preflight) requests, even though your POST requests are working fine. Let me clarify why this happens in API Management and the steps to resolve it.

Fix recommended steps

1. Move the <cors> block to the very top of the <inbound> pipeline, before any custom policies.
2. Avoid using <origin>@((string)context.Variables["corsOrigin"])</origin> inside <cors>. Instead, use a <choose> block outside the CORS policy and inject <cors> only when a valid origin is matched.
3. Do not return <origin></origin> empty — if corsOrigin resolves to empty, APIM responds with 500.
4. If possible, explicitly list known subdomains (wildcard origins with allow-credentials=true are not supported).

1. Debug tracing does also not work. There is no trace-id returned when the request, even with a valid Apim-Debug-Authorization header.

• In API Management, debug tracing does not log OPTIONS (preflight) requests. This is intentional, as only the <cors> policy is executed for OPTIONS, while the rest of the inbound/outbound pipeline is skipped.
• Because the request never goes through full policy processing, APIM does not generate a trace ID even if the Ocp-Apim-Debug-Authorization header is included.
• To troubleshoot OPTIONS requests, the recommended method is to use APIM Gateway logs in Azure Monitor / Log Analytics, where you can review request/response details, status codes, and CORS headers. Debug tracing is only available for standard requests (e.g., GET, POST), not for preflight OPTIONS.

2. Why do we get this error on OPTIONS preflight?

• In APIM, only the <cors> policy is executed for OPTIONS requests. If the <cors> policy isn’t placed first in the <inbound> section, or if it evaluates an empty/invalid origin, APIM fails to construct a valid CORS response and returns a 500 Internal Server Error instead of the expected headers.
• For preflight (OPTIONS) requests, only the CORS policy is evaluated. Any other policies in the inbound pipeline are ignored.

3.Where do I get more information about the cause of the error?

Enable APIM Gateway logs in Azure Monitor / Log Analytics.

Query with Kusto to confirm OPTIONS responses, status codes, and response headers.

AzureDiagnostics

where ResourceType == "APIMGatewayLogs"

where OperationName == "IncomingRequest"

where HttpMethod == "OPTIONS"

project TimeGenerated, clientIp_s, RequestUri_s, HttpStatusCode_d, BackendTimeMs_d, ResponseSize_s, CorrelationId_g

order by TimeGenerated desc

check the actual CORS header values that APIM returned

AzureDiagnostics

where ResourceType == "APIMGatewayLogs"

where HttpMethod == "OPTIONS"

project TimeGenerated, RequestUri_s, HttpStatusCode_d, ResponseHeaders_s

order by TimeGenerated desc

You won’t see deep trace steps, but you can confirm that the backend was skipped and APIM itself answered the OPTIONS.

Refer document: https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-use-azure-monitor?utm_source

4. Is there a more easy way for wildcard subdomains in the allowed-origins?

• In Azure API Management, you cannot enable CORS allowed credentials when the allowed origin is set to a wildcard (*). This is because combining AllowAnyOrigin with AllowCredentials is insecure and may expose your API to risks such as cross-site request forgery (CSRF).
• While CORS in APIM does support wildcard origins, there are key restrictions. If you need to allow credentials, you should avoid using * and instead configure either specific origins or a wildcard subdomain to maintain security.
• The recommended approach is to extract the Origin header and conditionally allow it if it matches your domain pattern, then echo it back in the response.

With these changes, OPTIONS requests should succeed without 500 errors, and you’ll have better visibility into what APIM is returning.

For more details, you can refer to the following documentation:

https://learn.microsoft.com/en-us/azure/api-management/cors-policy?utm_source

I hope this helps, please let me know if you have any further questions

Hi Ivo Bathke, following up to see if you have a chance to check my previous response and helped do let me know if you have any further questions on this. 

Thank you @Sandhya Kommineni for the response.

Appearently I am follwing the recommended approach:

The recommended approach is to extract the Origin header and conditionally allow it if it matches your domain pattern, then echo it back in the response.

Regarding logging: I am currently waiting for approval for creating a Application Insights Instance.

I moved the <cors> block inside the <when> block, so it will only rendered when the Origin header matches the condition.

<choose>
            <when condition="@{
            var origin = context.Variables.GetValueOrDefault<string>("requestOrigin");
            // List of allowed exact origins
            var allowedOrigins = new[] {
                "http://localhost:3000",
                "https://production",
                "https://dev"
            };
            return allowedOrigins.Contains(origin) || origin.EndsWith(".staging.example");
            }">
                <set-variable name="corsOrigin" value="@((string)context.Variables["requestOrigin"])" />
                <cors>
                    <allowed-origins>
                        <origin>@((string)context.Variables["corsOrigin"])</origin>
                    </allowed-origins>
                    <allowed-methods preflight-result-max-age="10">
                        <method>POST</method>
                        <method>GET</method>
                    </allowed-methods>
                    <allowed-headers>
                        <header>*</header>
                    </allowed-headers>
                </cors>
            </when>
            <otherwise>
                <set-variable name="corsOrigin" value="" />
            </otherwise>
        </choose>

However now I get an 404 for the OPTIONS request:
{

"statusCode": 404,

"message": "Resource not found"

}

The POST request still works.

Allow-credentials attribute was set to false and is removed now to allow wildcard subdomains.

Why do I get a 404 now on the OPTIONS request?

Hi Ivo Bathke, Thanks for sharing your output

In APIM, when you see a 404 on an OPTIONS request, it usually means that the request didn’t match any operation in your API for that route. Even though you have a CORS policy, APIM still needs the OPTIONS request to map to a valid API path and verb if it can’t find one, it returns 404.

For OPTIONS requests, APIM skips the full policy pipeline and only checks for a top-level <cors> policy if it’s missing, APIM can’t respond and returns a 404.

Recommended steps to follow:
You don’t need to explicitly define OPTIONS operations in your API.

• Place the <cors> policy at the very top of the inbound pipeline, ideally outside of <choose>.
• When <cors> is present at the top level, APIM will automatically handle OPTIONS requests.
• If you keep <cors> inside a <choose> and the condition doesn’t match. APIM won’t process the OPTIONS request, which results in a 404.

Try moving <cors> back to the top-level inbound, and use <choose> only to decide the value of the allowed origin.

Example: <inbound>

<set-variable name="requestOrigin" value="@(context.Request.Headers.GetValueOrDefault("Origin",""))" />

<choose>

    <when condition="@{

        var origin = context.Variables.GetValueOrDefault<string>("requestOrigin");

        var allowedOrigins = new[] {

            "http://localhost:3000",

            "https://production",

            "https://dev"

        };

        return allowedOrigins.Contains(origin) || origin.EndsWith(".staging.example");

    }">

        <set-variable name="corsOrigin" value="@((string)context.Variables["requestOrigin"])" />

    </when>

    <otherwise>

        <set-variable name="corsOrigin" value="" />

    </otherwise>

</choose>

<cors>

    <allowed-origins>

        <origin>@((string)context.Variables["corsOrigin"])</origin>

    </allowed-origins>

    <allowed-methods preflight-result-max-age="10">

        <method>POST</method>

        <method>GET</method>

    </allowed-methods>

    <allowed-headers>

        <header>*</header>

    </allowed-headers>

</cors>

</inbound>

The POST request still works because POST requests do run the whole pipeline, including your <when> block. That’s why the actual call succeeds, but the preflight OPTIONS fails.

When <cors> was at the top level in <inbound>, APIM could handle OPTIONS correctly, but once it was moved inside a <when> block, APIM doesn’t go inside so, skipped it for OPTIONS requests, and with no CORS response returned, APIM defaulted to 404.

If you really want <cors> inside <when>, then you must also explicitly define an OPTIONS operation in your API design (via OpenAPI spec or in APIM) otherwise APIM won’t find a match and returns 404.

I hope this helps, please let me know if you have any further questions

@Sandhya Kommineni it does not work.
It is also basically what I had in the first question.

I reduced the script to just use a context variable and then it fails.
Seems APIM policies are not able to process variables in the cors block.
Can you confirm this?

<policies>
    <inbound>
        <set-variable name="origin" value="https://staging.example.com" />
        <cors>
            <allowed-origins>
                <origin>@((string)context.Variables.GetValueOrDefault("origin"))</origin>
            </allowed-origins>
            <allowed-methods preflight-result-max-age="10">
                <method>POST</method>
                <method>GET</method>
            </allowed-methods>
            <allowed-headers>
                <header>*</header>
            </allowed-headers>
        </cors>
        <base />
        <!-- Call backend -->
        <set-backend-service base-url="https://thirdpartyapi" />
    </inbound>
    <outbound>
        <base />
    </outbound>
    <on-error />
    <backend>
        <base />
    </backend>
</policies>