Comprehensive Guide to Multiple Domain CORS Configuration

Technical Challenges in Multi-Domain CORS Configuration

Cross-Origin Resource Sharing (CORS) has become an essential technology in modern web development, enabling browsers to make cross-domain requests to servers. However, developers frequently encounter scenarios where they need to allow multiple specific domains to access resources, rather than simply using the wildcard '*'. While convenient, the wildcard approach introduces significant security risks by permitting any domain to access resources, potentially leading to sensitive data exposure.

According to HTTP specifications, the Access-Control-Allow-Origin response header can only contain a single domain or the wildcard '*', and cannot directly list multiple domains. This means that syntax like 'Access-Control-Allow-Origin: http://domain1.example, http://domain2.example' is invalid and will be rejected by browsers. This limitation necessitates more intelligent server-side solutions.

Apache Server Configuration Approach

For environments using Apache servers, dynamic multi-domain CORS support can be achieved through .htaccess files. This method leverages Apache's mod_headers module, using SetEnvIf directives to dynamically set response headers based on the request's Origin header.

The following complete configuration example specifically enables CORS for font files (such as TTF, OTF, WOFF, etc.):

<FilesMatch "\.(ttf|otf|eot|woff|woff2)$">
    <IfModule mod_headers.c>
        SetEnvIf Origin "http(s)?://(www\.)?(google\.com|staging\.google\.com|development\.google\.com|otherdomain\.example|dev02\.otherdomain\.example)$" AccessControlAllowOrigin=$0
        Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
        Header merge Vary Origin
    </IfModule>
</FilesMatch>

The core of this configuration lies in the SetEnvIf directive, which uses regular expressions to match the request's Origin header. If the Origin matches predefined domain patterns (supporting both HTTP and HTTPS, optionally including www subdomains), it stores the Origin value in the AccessControlAllowOrigin environment variable. The Header directive then sends this value as the Access-Control-Allow-Origin response header to the client.

Particular attention should be paid to the 'Header merge Vary Origin' line. The Vary header informs caching servers that response content varies based on different Origin request headers, which is crucial for proper caching of CORS responses. Without this header, caching servers might incorrectly return the same CORS headers for requests from different Origins.

PHP Dynamic Response Implementation

For PHP-based applications, CORS requests can be handled dynamically through server-side code. This approach offers greater flexibility and can be integrated into application logic.

The following PHP code demonstrates how to check the request Origin and set appropriate CORS headers:

$http_origin = $_SERVER['HTTP_ORIGIN'];

if ($http_origin == "http://www.domain1.com" || $http_origin == "http://www.domain2.com" || $http_origin == "http://www.domain3.com")
{  
    header("Access-Control-Allow-Origin: $http_origin");
}

The advantage of this method is the ability to integrate domain whitelist checks directly into application logic. Developers can extend the conditional checks as needed, such as adding additional security validations or access logging. However, this approach requires repeating similar code at each endpoint requiring CORS support, or handling it uniformly through middleware.

Advanced Middleware Solutions

For large applications or API services, using dedicated CORS middleware provides a more elegant solution. Here's a PHP middleware implementation based on PSR-7 standards:

<?php
namespace Middleware;

class CorsMiddleware
{
    protected $cors = [
        'https://somedomain.com' => ['GET', 'POST'],
        'http://somedomain.com' => ['GET', 'POST'],
        'https://dev.somedomain.com' => ['DELETE', 'PUT', 'POST']
    ];

    public function run($request, $response, $next)
    {
        $response = $next($request, $response);
        $origin = isset($_SERVER['HTTP_ORIGIN']) ? $_SERVER['HTTP_ORIGIN'] : 'none';
        return $this->getResponse($response, $origin, $this->cors);
    }

    private function getResponse($response, $origin, $cors)
    {
        if (isset($cors['*'])) {
            $origin = '*';
        }
        
        if (!isset($cors[$origin])) {
            return $response;
        }
        
        return $response
            ->withHeader('Access-Control-Allow-Origin', $origin)
            ->withHeader('Access-Control-Allow-Methods', implode(', ', $cors[$origin]));
    }
}

This middleware not only supports multiple domains but also allows specification of permitted HTTP methods for each domain. This granular control is particularly useful for RESTful APIs, ensuring different clients can only perform authorized operations.

Configuration Considerations Across Platforms

CORS configuration may vary across different deployment environments. For instance, on static website hosting platforms like Netlify, while CORS headers can be configured in _headers files, they typically only support fixed values and cannot dynamically adjust based on request Origin. In such cases, alternative solutions like edge functions or proxy services may need to be considered.

In cloud services like AWS API Gateway, although configuration interfaces might suggest support for multiple origins, it's essential to ensure that final responses contain only a single domain. This typically requires implementing logic in mapping templates or integration responses to determine and set the correct Origin header.

Security Best Practices

Security should be the primary consideration when implementing multi-domain CORS. Here are some important security recommendations:

First, always validate the format and content of the Origin header to prevent header injection attacks. Regular expressions should strictly match expected domain patterns, avoiding overly permissive patterns.

Second, consider implementing rate limiting and access logging to monitor unusual CORS request patterns, which helps identify potential attack behaviors early.

For requests requiring credentials (such as those including cookies or HTTP authentication), always set Access-Control-Allow-Credentials: true and ensure Access-Control-Allow-Origin is not the wildcard '*', as specifications prohibit wildcard usage in this context.

Finally, regularly review and update the list of allowed domains, removing domains that are no longer needed to reduce the attack surface.

Testing and Validation

After implementing CORS configuration, thorough testing is crucial. Configuration correctness should be verified using different browsers and tools. Particular attention should be paid to testing:

Whether allowed domains can normally access resources; Whether disallowed domains are properly rejected; Whether preflight requests (OPTIONS) are correctly handled; Whether credentialed requests are securely processed; Whether caching behavior meets expectations.

Browser developer tools can monitor network requests to inspect actual request and response headers, ensuring CORS headers are properly set. Command-line tools like curl can also be used for automated testing.

By comprehensively applying these techniques and methods, developers can build secure, flexible multi-domain CORS solutions that meet business requirements while ensuring system security.