CORS provides user agents, typically browsers, with a way to request access to restricted resources that reside on external domains.

For security purposes, the default behavior of web applications is to follow the same-origin policy. This means that a web application can access data residing on another web application (for example, through an AJAX request) only if both applications have the same origin. After enabling CORS for your API delivery configuration, you can allowlist selected external origins and allow user agents that send requests from these origins to access resources within your API.

In API Gateway you can specify the origin hostnames, HTTP methods, and headers that edge servers should accept in incoming CORS requests. Edge servers first determine the type of an incoming CORS request (preflight, simple, or actual) and then validate the request against the list of acceptable hostnames, methods, and headers.

Configure CORS

Cross-origin resource sharing (CORS) settings allow user agents to request resources from external domains. You can specify origin hostnames, methods, and headers that you want to accept via HTTP response headers.

📘

API

You can also complete this task by using the API Endpoints API. Run the Edit CORS settings operation. Learn more about Akamai's APIs.

1. On the API Definitions page, in the Registered APIs section, click the ellipsis icon (...) associated with the API configuration you want to configure CORS settings for.

2. From the menu, select Manage versions.

3. In the Version history panel, click the ellipsis icon (...) associated with the API configuration version you want to configure CORS settings for.

4. From the list of delivery options, select Cross origin resource sharing (CORS).

5. On the CORS settings page, set the Enable CORS switch to Yes.

   📘

   This rule is a part of the rules tree in Property Manager, so other rules related to the CORS settings and triggered later in the process will overwrite this one.

6. Optional: To accept credentialed HTTP requests, set the Allow credentials switch to Yes.
   Credentials may be cookies or TLS client certificates.

7. If you allowed credentials, in the Preflight max age field, enter the maximum time (in seconds) for caching responses to preflight requests.

   📘

   The value must be between 1 and 1000000. The Preflight max age value corresponds to the Access-Control-Max-Age response header value.

8. In the Allowed origins text box, enter the hostnames that you want to allow via the Access-Control-Allow-Origin response header.

   📘

   The hostnames that you enter must start with httpor https. For detailed hostname syntax requirements, refer to RFC-952 and RFC-1123 specifications.

   If you did not allow credentials, you can enter the wildcard (*) sign to accept all hostnames.

9. In the Allowed methods box, select the HTTP methods that you want to allow via the Access-Control-Allow-Methodsresponse header.

10. In the Allowed headers text box, enter the names of HTTP headers that you want to allow via the Access-Control-Allow-Headersresponse header.

11. In the Expose headers text box, enter the names of headers that you want to expose via the Access-Control-Expose-Headersresponse header.
    By default, clients can access the following simple response headers:

    • Cache-Control
    • Content-Language
    • Content-Type
    • Expires
    • Last-Modified
    • Pragma
      If you want to make other headers accessible to clients, list these headers in the Expose headers box.

12. Click Save.