Web Browsers and Cross Origin Resource Sharing

Question

The CORS spec states that if a request method and headers are not simple (http://www.w3.org/TR/cors/#simple-cross-origin-request) then a preflight HTTP OPTIONS request is sent to see if the request is allowed by the server.

My server does not respond with any CORS specific headers, so I am assuming this means the request will be denied. A security firm recently told me that this means the request will always be accepted if I don't specifically deny it with CORS headers, but I find this hard to believe.

Also, some older browsers don't implement CORS at all, so I am wondering if there is a security hole here that these browsers may be able to bypass the CORS check? Or do these browsers just always deny everything?

Summary: I never want cross origin requests to be accepted. Is there a security hole with just pretending CORS doesn't exist?

Answer 1

No. There is no security hole in just pretending CORS doesn't exist. CORS is an opt-in policy. As long as your server never sends any CORS headers (never opts in), browsers will continue to use the standard same-origin policy. You can pretend CORS doesn't exist, to keep your life simple: that's a perfectly reasonable strategy.

CORS is optional: you can use it if you want its extra features, but it is also perfectly fine to ignore it and never use it. This is by design. Anything else would be crazy. There are millions of web sites out there which were written before CORS and aren't ever going to be changed. Designing a standard which overnight made all of those websites would be crazy. The CORS standards writers aren't crazy. They didn't do that. (In fact, they took great pains not to do that!)

I suspect there has been some miscommunication or misunderstanding with your security firm (or possibly your security firm is just wrong). As far as I know, it's fine for a web application to never send any CORS headers.

That said, you do need to understand CSRF. CSRF is a fundamental vulnerability on the web (one which far predates CORS, and is orthogonal to CORS). So, please do read up on it. You'll find a lot of great resources on CSRF on the OWASP web pages and on this site. The standard defense against CSRF is to use CSRF tokens for all HTTP requests that could possibly have any side effect.

Answer 2

Are you trying to secure the client or the server? It is my understanding that CORS is intended to provide a way for client-side applications (e.g. scripts) to access resources outside of the "same-origin-policy". Standards-compliant browsers should not allow scripts to retrieve resources outside of their domains (e.g. via AJAX request) in the absence of the Access-Control-Allow-Origin HTTP header, so I think the answer to your question is that you do not have to worry about it. However, CORS / the same-origin policy is enforced by the client, so I do not know what you could do on the server-side to deny cross-origin requests other than to not explicitly allow them with that header.

Answer 3

When your web server gets a request, it sees only what the client sent to it. It has no information of what's happening in the browser, of even if there is a browser at all (suppose someone used curl or wget to make the request). So, the responsibility of preventing CSRF is mostly the browser's, and if any older browser do nothing to prevent it those requests will be honored.

There are many techniques for preventing CSRF that does not deal with CORS at all. One of the most effective AFAIK is the use of a CRSF token: send a random token to the client (storing it in the site's cookie) and expect it back in every submission that you need protected. Assuming you're using SSL, there's no way for an attacker (that does not have access to the cookie) to know what the token is, so he can't forge a valid request.