CORS

APPLIES TO: All API Management tiers

The cors policy adds cross-origin resource sharing (CORS) support to an operation or an API to allow cross-domain calls from browser-based clients.

<cors allow-credentials="false | true" terminate-unmatched-request="true | false">
    <allowed-origins>
        <origin>origin uri</origin>
    </allowed-origins>
    <allowed-methods preflight-result-max-age="number of seconds">
        <method>HTTP verb</method>
    </allowed-methods>
    <allowed-headers>
        <header>header name</header>
    </allowed-headers>
    <expose-headers>
        <header>header name</header>
    </expose-headers>
</cors>

• Policy sections: inbound
• Policy scopes: global, workspace, product, API, operation
• Gateways: classic, v2, consumption, self-hosted, workspace

• You may configure the cors policy at more than one scope (for example, at the product scope and the global scope). Ensure that the base element is configured at the operation, API, and product scopes to inherit needed policies at the parent scopes.
• Only the cors policy is evaluated on the OPTIONS request during preflight. Remaining configured policies are evaluated on the approved request.

• This policy can only be used once in a policy section.

CORS is an HTTP header-based standard that allows a browser and a server to interact and determine whether or not to allow specific cross-origin requests (XMLHttpRequest calls made from JavaScript on a web page to other domains). This allows for more flexibility than only allowing same-origin requests, but is more secure than allowing all cross-origin requests.

CORS specifies two types of cross-origin requests:

• Preflighted (or "preflight") requests - The browser first sends an HTTP request using the OPTIONS method to the server, to determine if the actual request is permitted to send. If the server response includes the Access-Control-Allow-Origin header that allows access, the browser follows with the actual request.

• Simple requests - These requests include one or more extra Origin headers but don't trigger a CORS preflight. Only requests using the GET and HEAD methods and a limited set of request headers are allowed.

Configure the cors policy in API Management for the following scenarios:

• Enable the interactive test console in the developer portal. Refer to the developer portal documentation for details.

  Note

  When you enable CORS for the interactive console, by default API Management configures the cors policy at the global scope.

• Enable API Management to reply to preflight requests or to pass through simple CORS requests when the backends don't provide their own CORS support.

  Note

  If a request matches an operation with an OPTIONS method defined in the API, preflight request processing logic associated with the cors policy will not be executed. Therefore, such operations can be used to implement custom preflight processing logic - for example, to apply the cors policy only under certain conditions.

• Subscription key in header - If you configure the cors policy at the product scope, and your API uses subscription key authentication, the policy won't work when the subscription key is passed in a header. As a workaround, modify requests to include a subscription key as a query parameter.
• API with header versioning - If you configure the cors policy at the API scope, and your API uses a header-versioning scheme, the policy won't work because the version is passed in a header. You may need to configure an alternative versioning method such as a path or query parameter.
• Policy order - You may experience unexpected behavior if the cors policy is not the first policy in the inbound section. Select Calculate effective policy in the policy editor to check the policy evaluation order at each scope. Generally, only the first cors policy is applied.
• Empty 200 OK response - In some policy configurations, certain cross-origin requests complete with an empty 200 OK response. This response is expected when terminate-unmatched-request is set to its default value of true and an incoming request has an Origin header that doesn’t match an allowed origin configured in the cors policy.

This example demonstrates how to support preflight requests, such as those with custom headers or methods other than GET and POST. To support custom headers and other HTTP verbs, use the allowed-methods and allowed-headers sections as shown in the following example.

<cors allow-credentials="true">
    <allowed-origins>
        <!-- Localhost useful for development -->
        <origin>http://localhost:8080/</origin>
        <origin>http://example.com/</origin>
    </allowed-origins>
    <allowed-methods preflight-result-max-age="300">
        <method>GET</method>
        <method>POST</method>
        <method>PATCH</method>
        <method>DELETE</method>
    </allowed-methods>
    <allowed-headers>
        <!-- Examples below show Azure Mobile Services headers -->
        <header>x-zumo-installation-id</header>
        <header>x-zumo-application</header>
        <header>x-zumo-version</header>
        <header>x-zumo-auth</header>
        <header>content-type</header>
        <header>accept</header>
    </allowed-headers>
    <expose-headers>
        <!-- Examples below show Azure Mobile Services headers -->
        <header>x-zumo-installation-id</header>
        <header>x-zumo-application</header>
    </expose-headers>
</cors>

• Cross-domain

For more information about working with policies, see:

• Tutorial: Transform and protect your API
• Policy reference for a full list of policy statements and their settings
• Policy expressions
• Set or edit policies
• Reuse policy configurations
• Policy snippets repo
• Azure API Management policy toolkit
• Get Copilot assistance to create, explain, and troubleshoot policies