The best way to figure out what is happening is to check the IIS logs. That should be the first thing to do in a similar situation. If you notice something like "Rejected-By-UrlScan", you need to check the URLScan configurations located in
Windows drive (C: most probably) > Windows > system32 > inetsrv > urlscan > UrlScan.ini
Open the above file in a text editor and look for [AllowVerbs] section. If OPTIONS not specified in the [AllowVerbs] section along with others (GET, POST etc), add OPTIONS. To do that, you may need to open the file in a text editor with administrative privileges and save. That's it.
Recently we installed URLScan on our front-end servers for one of SharePoint project in order to redirect 404 URL's to the relevant pages, to improve the SEO. But after the deployment, another Web API project hosted in the same machines failed to serve OPTIONS request.
When checked the browser console errors, we thought of CORS issue and tried custom header appending etc in the web.config but nothing worked out, and later we find out the issue with URLScan. When we checked the URLScan configuration, by default only GET, PUT and POST are included in the [AllowVerbs] section. So our OPTIONS request where not even reached our website and being rejected by the URLScan module. Once we added OPTIONS in the [AllowVerbs] section, everything resumes working fine.
About the author
Adding rewrite rules in release config is handy so that it will not affect during Debug mode.
When considering SEO, either you have to stick with www versioned url or non-www URLs. Having both accessible for a domain is a bad practice.
Use IIS rewrite rule to redirect (301) all www requests to non-www.
Use IIS Rewrite rule to redirect all HTTP request to HTTPS.
Use the provided rewrite rule to redirect HTTPS requests to HTTP.
Restrict access to your website using IIS IP security