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?

3 Answers
3

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.

My comment about protecting against CSRF was misleading. What I forgot to mention was that the specific server endpoint drops all requests that are not BOTH post and content-type: application/json. The thing I am actually trying to understand from this is that for that specific scenario (request MUST be post and application/json) if clients would be protected from CSRF attacks? I ask because I can't figure out how to allow a browser to make this type of request without a server explicitly allowing it through CORS.
–
Jarrod EverettAug 28 '12 at 12:10

@JarrodEverett, That's a different question, and I suggest asking it on a separate question (click "Ask Question" to ask a different one). The short version is that I don't immediately know of an attack, but at the same time I would not rely upon that to be secure -- I'd recommend you use CSRF tokens, like everyone else does.
–
D.W.Aug 28 '12 at 18:46

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.

Protecting clients from CSRF. I agree with you, and am only confused because a security firm recently told me that because I don't explicitly handle CORS I am vulnerable. I can't find enough data that I am correct on this guess though
–
Jarrod EverettAug 27 '12 at 20:54

Maybe there was some misunderstanding between you two. Could it be that they were talking about your server-side applications checking the Origin header and mistakenly saying Access-Control-Allow-Origin header instead? I believe you need to ensure that the application checks that header to help protect against CSRF.
–
iX3Aug 27 '12 at 22:45

Perhaps, but they wrote that my "server does not return the proper CORS headers to deny access for cross domains. Furthermore, there are older browsers that do not even implement CORS that are also vulnerable to CSRF attacks."
–
Jarrod EverettAug 28 '12 at 1:33

1

I also think there has been some miscommunication or confusion by your security firm. (a) CORS is not necessary to stop CSRF. (b) Checking the Origin header is not necessary to stop CSRF. (c) Browsers are not vulnerable to CSRF; CSRF is a server-side vulnerability, not a browser vulnerability. (I don't know what old browser have to do with it, either.) (d) If you don't opt into CORS, you'll remain protected by the standard same-origin policy (so cross-domain requests can be initiated, but the initiator won't be able to read the response).
–
D.W.Aug 28 '12 at 6:23

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.

I agree with this, but I am mostly wondering if random clients who are browsing the web and are sent to a malicious website that plants a CSRF attack against them are safe. I guess there are older browsers that would not honor some of these safeguards, but I can't personally find one that does in this context
–
Jarrod EverettAug 27 '12 at 20:53

That will depend on what those requests do. If a user is authenticated in your site and another site has an element <img src="your.site/do_something"/> your server will happily process the request (which will also send your cookie), unaware of where it's coming from (unless it checks - and enforces - the HTTP Referer and Origin). The attacker will not see if the request succeeded or not, but it still can have side effects in your server, unless you take explicit measures to avoid that.
–
mgibsonbrAug 27 '12 at 21:19

True, but that is only in the case of a CORS defined simple request. I am referring to a non-simple request like say a POST with Content-Type: application/json. Lets assume the server rejects any request that is not of this type (ASP.NET page method default settings are like this)
–
Jarrod EverettAug 27 '12 at 21:33

1

@JarrodEverett: whether those clients are safe depends upon whether your web application has CSRF vulnerabilities or not. If your web application properly defends against CSRF (e.g., using a CSRF token, as mgibsonbr explains), then it won't be vulnerable. If it doesn't, then it will be vulnerable. You might want to review some background material on CSRF vulnerabilities, before diving into CORS. I thought you've gotten yourself twisted up in the CORS scenario, when you need to understand basic CSRF first. If you don't send any CORS headers, you can ignore CORS, and focus on vanilla CSRF.
–
D.W.Aug 28 '12 at 6:26