Headers disabled on web server

Question

Our company maintains PCI compliance (along with a few others). As part of our most recent security audit it was determined by our infrastructure team and auditors that OPTIONS headers should be completely disabled as it posed a security threat.

We use .NET web APIs (on multiple subdomains) with Angular 6/7 websites. With the OPTIONS headers now disabled, the preflight calls from Angular are rejected and our apps fail at the first API call to another subdomain (e.g. Authentication, which is one of our first functions and lives on auth.mycompany.com with our app on app.mycompany.com).

I've done quite a bit of reading (and would be THRILLED to have someone mark this as a duplicate if it leads to a solution:) however, I have not been able to find any solutions that would work. Most articles call for white listing valid OPTIONS calls (Why is HTTP Options request insecure and https://security.stackexchange.com/questions/138567/why-should-the-options-method-not-be-allowed-on-an-http-server are two examples) or setting up a proxy on the same subdomain (Preflight CORS requests with Basic Authentication in Angular 2).

My question is, is there a way to configure the OPTIONS header that will allow us to pass our security scans and still allow our CORS calls from Angular?

Answer 1

Our company maintains PCI compliance (along with a few others). As part of our most recent security audit it was determined by our infrastructure team and auditors that OPTIONS headers should be completely disabled as it posed a security threat.

I agree that a broad block of all OPTIONS across all domains is a valid security default, but they should allow some OPTIONS requests through to the correct servers as it is part of the HTTP specification.

Some security teams block all POST requests as standard practice, and you have to request which POST requests are allowed into the network.

We can't tell you if this is a good policy or not.

My question is, is there a way to configure the OPTIONS header that will allow us to pass our security scans and still allow our CORS calls from Angular?

This is a standard security check done by web browsers when a request is made to another domain. That's something you can't change.

Here is a list of your options at this point

• request that the OPTIONS be allowed for web servers in question. Tell the security team that the servers will be modified to yield OPTIONS responses that are strict in nature and ensure security.
• host the Angular web application on the same domain so that an OPTIONS request is not made by the browser.
• change all the API calls so that only GET requests without a body are made to the APIs (empty GET requests are exempt from OPTIONS pre-flight requests).
• create an API proxy on the same domain as the Angular application, and have the proxy make all the API calls to the other domain (back-end servers don't make OPTIONS requests).

Check with your security team first before implementing any of the above.