Keywords: CORS | Access-Control-Allow-Origin | ASP.NET | IIS Configuration | Cross-origin Requests
Abstract: This article provides a comprehensive exploration of technical solutions for configuring multiple allowed cross-origin domains in ASP.NET applications. By analyzing the CORS protocol specifications, it reveals the single-value limitation of the Access-Control-Allow-Origin header and presents two implementation approaches using IIS URL Rewrite module and server-side code validation. The paper details the processing mechanism of HTTP_ORIGIN request headers and demonstrates how to securely implement multi-domain CORS support through conditional matching and dynamic response header settings, while avoiding security risks associated with wildcard * usage.
CORS Protocol Fundamentals and Multi-domain Configuration Challenges
Cross-Origin Resource Sharing (CORS) is a critical technology in modern web application development, enabling browsers to make cross-origin requests to servers from different domains. According to W3C CORS specifications, the Access-Control-Allow-Origin response header can only contain a single origin value, which is strictly enforced by browsers. Many developers attempt to specify multiple domains in web.config using comma-separated, space-separated, or semicolon-separated formats, such as: <add name="Access-Control-Allow-Origin" value="http://localhost:1506, http://localhost:1502" />, but these approaches fail because browsers only recognize the first value or completely reject such formats.
IIS URL Rewrite Based Solution
For environments using IIS 7.5 or later with URL Rewrite Module 2.0 installed, dynamic CORS header configuration can be achieved through outbound rules. The core principle involves using the HTTP_ORIGIN server variable to obtain the request origin, validating domain whitelist through regular expression pattern matching, and then dynamically setting the matched origin value as the response header.
The configuration example demonstrates how to create a rule named AddCrossDomainHeader: <rule name="AddCrossDomainHeader"><match serverVariable="RESPONSE_Access_Control_Allow_Origin" pattern=".*" /><conditions logicalGrouping="MatchAll" trackAllCaptures="true"><add input="{HTTP_ORIGIN}" pattern="(http(s)?://((.+\.)?domain1\.com|(.+\.)?domain2\.com|(.+\.)?domain3\.com))" /></conditions><action type="Rewrite" value="{C:0}" /></rule>. Note that the rewrite module uses underscores instead of hyphens in response header names, so RESPONSE_Access_Control_Allow_Origin corresponds to the actual Access-Control-Allow-Origin header.
Server-side Code Validation Approach
In ASP.NET applications, more flexible multi-domain CORS control can be implemented programmatically. The basic workflow includes three key steps: first, obtaining the request origin from Request.Headers["Origin"]; second, validating whether the origin exists in a predefined whitelist; and finally, setting the corresponding CORS response headers upon successful validation.
Implementation code example: if (ValidateRequest()) { Response.Headers.Remove("Access-Control-Allow-Origin"); Response.AddHeader("Access-Control-Allow-Origin", Request.UrlReferrer.GetLeftPart(UriPartial.Authority)); Response.Headers.Remove("Access-Control-Allow-Credentials"); Response.AddHeader("Access-Control-Allow-Credentials", "true"); Response.Headers.Remove("Access-Control-Allow-Methods"); Response.AddHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS"); }. This approach allows implementing complex business logic within the ValidateRequest method, such as database query validation or dynamic domain list management.
Security Considerations and Best Practices
Avoiding wildcard * usage is an important security practice since it permits any domain to access resources, potentially leading to sensitive data exposure. Cases from reference articles indicate that the single-value limitation of CORS headers applies equally across different hosting platforms (like Netlify). When supporting multiple subdomains, consider using regular expression pattern matching, such as (.+\.)?example\.com to match all subdomains of example.com.
In actual deployments, it's recommended to store domain whitelists in configuration files for easier maintenance and updates. For production environments, comprehensive logging and monitoring mechanisms should be implemented to track CORS request origins and outcomes, enabling timely detection of abnormal access patterns.
Performance Optimization and Scalability
For high-traffic applications, the IIS URL Rewrite solution offers better performance than server-side code approaches since it handles requests directly at the IIS level, avoiding the overhead of entering the application pool. However, code-based solutions provide greater flexibility for integrating more complex business logic. During implementation, consider caching validated domain lists to reduce repetitive validation overhead.
When supporting large numbers of domains, using hash tables or dictionary data structures for whitelist storage is recommended to achieve O(1) time complexity for lookup operations. Additionally, consider implementing domain grouping management, classifying domains by business function or security level for processing.