2

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?

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
ryanlifferth
  • 125
  • 1
  • 1
  • 6

1 Answers1

2

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.

Reactgular
  • 52,335
  • 19
  • 158
  • 208
  • Thanks @cgTag, those were many of the same options that we had come up with. I agree with you that our security team should allow some OPTIONS requests to go through. That is why I am curious to know how others in the industry are approaching this issue, if at all. If we allow any OPTIONS requests to go through, our scan would still fail and we would fail our security audit. – ryanlifferth Nov 15 '18 at 00:41
  • 1
    @ryanlifferth the security team has made some architectural design decisions about software development for you. They've imposed restrictions on what new modern technologies you are allowed to use. OPTIONS is part of the HTML5 new standard for CORS and RESTful APIs. If the corporate policy and culture is to do what the security team says you are allowed to do, then this tells you what kind of technology you are allowed to use. The culture of your company might not be ready for modern Angular and RESTful development. I have seem many corporate businesses that are 10 years behind the times. – Reactgular Nov 15 '18 at 00:59
  • 1
    @chTag - you are exactly right with your comment about the design decisions. Thank you so much for your responses, they confirmed a lot of information I had been gathering and ultimately helped me get to a successful resolution. I am writing up a description of this in case others devs come across similar circumstances. I would bet that this solution is ultimately solved by the browser providers, but for now your answer helped us move forward. – ryanlifferth Jan 03 '19 at 20:52