To enable CORS support for IIS, the web.config file needs to be configured manually. 1. Add the segment in , set the Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers headers, specifying the allowed sources, methods and request headers respectively. 2. Make sure to process preflight requests (OPTIONS) and enable IIS to respond correctly to such requests by configuring . 3. Check for conflicts with other modules, clear existing header information if necessary and configure it separately. 4. Restart IIS or recycle the application pool after modification to take effect. This method is suitable for scenarios where the framework does not use the CORS function.

When you're hosting a website or API on IIS and want to allow requests from another domain, you'll need to configure CORS policies. Internet Information Services (IIS) doesn't have built-in CORS settings like some modern frameworks do, but you can manage it using the web.config file.

Add CORS Headers in web.config

The most common way to enable CORS in IIS is by adding custom HTTP headers in your site's web.config file. This mimics how CORS works at the server level.

You'll want to add something like this inside the <system.webserver></system.webserver> section:

 <httpProtocol>
  <customHeaders>
    <add name="Access-Control-Allow-Origin" value="*" />
    <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
    <add name="Access-Control-Allow-Headers" value="Content-Type, Authorization" />
  </customHeaders>
</httpProtocol>

• Access-Control-Allow-Origin sets which domains are allowed. Use * for all, or specify a domain like https://example.com .
• Access-Control-Allow-Methods should include all HTTP methods your API accepts.
• Access-Control-Allow-Headers covers headers clients might send, such as Authorization or Content-Type .

Be careful with Access-Control-Allow-Credentials — only enable it if your frontend needs to send cookies or auth tokens cross-origin.

Handle Preflight Requests (OPTIONS)

Browsers often send an OPTIONS request before making certain types of cross-origin requests (like those with custom headers). You need to make sure IIS responses correctly to these.

In your web.config , make sure you have a handler for OPTIONS :

 <handlers>
  <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
  <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedModeV4.0" />
</handlers>

This tells IIS to pass the OPTIONS request through properly instead of blocking or ignoring it.

If you're using ASP.NET Web API alongside IIS, it's better to handle CORS at the application level using the [EnableCors] attribute — but not everyone has that setup.

Avoid Conflicts with Other Modules

Sometimes IIS modules like URL Rewrite , Dynamic Content Compression , or even Authentication modules can interfere with how CORS headers are sent.

Here are a few things to check:

• Make sure no other module is removing or overwriting your CORS headers.
• If you're using Windows Authentication, test whether it affects how credentials are handled cross-origin.
• In some cases, you may need to clear existing headers before adding your own:

 <customHeaders>
  <clear />
  <add name="Access-Control-Allow-Origin" value="https://yourdomain.com" />
  ...
</customHeaders>

Also, don't forget to restart IIS or recycle the app pool after making changes:

 iisreset

That's the core of setting up CORS in IIS manually. It's not as plug-and-play as some platforms, but once you get the headers right and handle preflight requests, it works reliably. Just be precise about what domains and methods you allow — especially in production environments.

Basically that's it.

The above is the detailed content of Configuring CORS (Cross-Origin Resource Sharing) Policies in IIS. For more information, please follow other related articles on the PHP Chinese website!