Dilemma of CORS Configuration

CORS (Cross-Origin Resource Sharing) is a security feature implemented by web browsers to restrict web pages from making requests to a different domain than the one that served the web page.??

This is done by executing preflight requests. For preflight requests, as opposed to straightforward ones, the browser initially dispatches an HTTP request using the OPTIONS method to the target resource on a different origin. This step is undertaken to verify whether it is secure to proceed with the actual request. These cross-origin requests undergo a preflight process due to their potential impact on user data.?

?

?

When dealing with APIs, especially in microservices or distributed architecture, CORS issues may arise when a client application hosted on one domain attempts to make requests to an API hosted on a different domain.?

The CORS policy can be configured at both the API Gateway level and the application level, and the choice often depends on the specific requirements and architecture of your system. Here are considerations for both options:?

Choice 1 - Configuring CORS at the API Gateway Level:?

Centralized Control:?

Configuring CORS at the API Gateway allows for centralized control over CORS policies for multiple APIs. This can be particularly beneficial in a microservices architecture where different services may have different CORS requirements.?

Simplified Configuration:?

Configuring CORS at the API Gateway can be more straightforward, as it allows you to set CORS policies in one place rather than configuring them separately for each service.?

Cross-Cutting Concern:?

CORS configuration is often considered a cross-cutting concern that is not specific to individual services. Placing it at the API Gateway level helps ensure consistent application of CORS policies across all services.?

Pre-flight request?

If a browser detects that a request requires a check to see if it is permissible, it will first send a preflight request.? This is an OPTIONS method to the same path as the original request, with headers for Origin, Access-Control-Request-Method and Access-Control-Request-Headers.? These will have the origin domain, intended HTTP method and which headers are intended to be sent.?

The gateway will check against its configuration to see if the path allows for that combination to be executed and will respond accordingly.? If the browser is told it is not permitted the request halts.? Otherwise, it will go ahead with a real request.?

Choice 2 - Configuring CORS at the Application Level:?

Fine-Grained Control:?

Some applications may require fine-grained control over CORS policies based on the specific functionality of each service. Configuring CORS at the application level allows each service to define its own CORS settings.?

Isolation of Concerns:?

CORS is a concern related to how a specific service interacts with clients. Configuring it at the application level allows for the isolation of concerns, making it clear how each service handles cross-origin requests.?

Flexibility:?

Different services within a system may have different requirements or security considerations. Configuring CORS at the application level provides the flexibility to adapt CORS policies based on the needs of each service.?

Pre-flight request:

Just like the API gateway example, the browser will send an OPTIONS request of what it intends to send.? This time the application itself is required to respond usually via a third-party library together with relevant environment-specific configuration.?

?

Best Practices for CORS:?

Combination of Both:?

In some cases, a combination of API Gateway-level and application-level CORS configuration may be appropriate. You can use the API Gateway for global CORS policies and allow individual services to override or customize CORS settings if needed.?

?

Consider Security Implications:?

When configuring CORS, consider the security implications. Ensure that only necessary domains are allowed and avoid overly permissive configurations to mitigate potential security risks.? If an overly permissive configuration has been allowed to reach production, it can take a great deal of effort and time to configure it properly.? Unexpected domains may have started using your services legitimately, and any changes made to your configuration may cause an incident with theirs.? You may need to start logging all Origin headers that use your service to ensure that all are accounted for.? This leaves your application exposed for longer than necessary until you can confidently apply the correct configuration.?

?

Conclusion?

In summary, the choice between configuring CORS at the API Gateway level or at the application level depends on factors such as the architecture of your system, the level of control required, and the specific CORS requirements of each service. Both approaches have their advantages, and the decision should align with the overall design and needs of your application.? Don’t be tempted to use wildcard origins as correcting the problem later can be much more expensive.?

?

Alternatively, you could design your application to avoid needing to configure CORS.? If all browser-based requests were routed to an application with the same domain, which acted as a proxy to the real services, then no pre-flight requests would be needed.?

Co-Authors: This article is co-authored by Nick Gomm - https://www.dhirubhai.net/in/nick-g-974872238/

?The opinions expressed are our own and do not represent the views of our employer?

??#Cloud, #BackendAPIs, #CORS, #Browser, #Security, #APIGateway, #APIs, #Microservices?