4

Modern browsers don't allow cross-origin requests - those must be explicitly allowed by CORS headers. But looking at Java back ends like Tomcat/Spring MVC I see that it's possible to reject requests from other origins on server side.

Since browsers handle this on their end - do we really need to care about it on server side? Well, there are Simple Requests which we do need to take care of, but those can easily be disabled by requiring some custom HTTP header. What about the rest of the cases?

1
  • I've changed the title of your question to match what you were actually asking: It is about detecting cross-origin requests, not about SOP. These are related but still different things. Dec 29, 2021 at 15:46

3 Answers 3

4

There is no reason to handle them on the backend as they can easily be spoofed.

The concept of CORS is to ensure one resource (say hacker.com) cannot access another resource (say facebook.com) in the browser unless the accessed resource gives permissions. This is only relevant in the context of a browser as the resources being accessed are cookies, headers and more and thus enforced by the browser to separate these two resources from each other.

By trying to enforce it on the backend, you aren't providing any additional security measures as the browser is the one holding the "sensitive" data. Additionally, the origin header can easily be spoofed. I assume the settings you see in Tomcat and Spring are just for setting the CORS settings to let the browser know what origin's to allow and what to deny.

19
  • No, I clearly see that they can reject CORS requests: github.com/quickhack/tomcat/blob/…. In SpringMVC rejection is configurable and is turned off by default. Dec 29, 2021 at 10:35
  • Rejecting AJAX requests by rejecting the pre-flights is possible. But where do you see the denial by origin's? I see configuration done for allowed origins but that's for the CROS header for the browser. Dec 29, 2021 at 10:39
  • Ah I see now in your edit to the post. Not sure what the login is behind that, once again, the origin can be spoofed anyways. Dec 29, 2021 at 10:40
  • 2
    The origin header is not spoofable in the browser. Dec 29, 2021 at 14:01
  • 1
    @BenVoigt, do we? If browser is malicious, then nothing can prevent it from sending a CORS request. It can even send requests w/o user involvement once the user is authenticated. Dec 30, 2021 at 4:47
1

The cross-origin nature of a request can be of interest on the server-side beyond allowing/disallowing the request for CORS purposes. In particular, you may want to implement a resource-isolation policy:

It is common for resources exposed by a given web application to only be loaded by the application itself, and not by other websites. In such cases, deploying a Resource Isolation Policy based on Fetch Metadata request headers takes little effort, and at the same time protects the application from cross-site attacks.

(source: Protect your resources from web attacks with Fetch Metadata)

6
  • 1
    This may soften the blow of legitimate browsers being turning into zombies executing a DDOS attack, it doesn't protect your resources from disclosure to an HTTPS client that wants them.
    – Ben Voigt
    Dec 29, 2021 at 22:41
  • @BenVoigt I never professed otherwise. An RIP isn't a substitute for authorization. Another important benefit, though, is that it allows you to save bandwidth if third-party Web origins try to load your content.
    – jub0bs
    Dec 29, 2021 at 22:59
  • OMG, I think this is a perfect case. I lure user with creds to a target CORS api to my website evildoer.com (user uses chrome of course) and I have a CORS request to an API that user has access to. The server 'should' deny that CORS request as evildoer.com should not be a whitelisted website. Thanks @jub0bs. I think this is a great example as attacker is luring users into an open hole where server just allows all domains on CORS. (I think????) Jun 17 at 10:17
  • @DeanHiller Huh? No, it is the browser than must deny the CORS request.
    – Ben Voigt
    Jun 17 at 15:39
  • @BenVoigt - I wish I had a forum so I could jump online in real-time and discuss with you...heh. I posted on the other longer thread above. Jun 18 at 12:21
0

I think you're trying to ask why servers have origin checks when it comes to protecting resources and sensitive actions. CORS will prevent the reading of sensitive data by malicious sites, but it will not prevent the posting of data to a server. An important step in added security to mitigate this is the now default same-site policy on cookies across all major browsers. However, security needs redundancies (what if same-site policy is set to lax accident?) and additional server checks are important.

For example, your bank would like to protect your account. If a malicious site tries to call your bank site requesting a withdrawal, the bank server should first check if the Origin header of the request matches the bank's domain (or aby of its whitelisted sites). If not, it should reject the request. Hidden form tokens provide another layer of protection against cross-origin writes. A rest client or curl call can spoof the origin as some comments note, but that doesn't matter because an attacker still needs access to the cookie key which resides in your browser. Back to the browser, CORS policy alone won't secure the server from processing a request as you can see.

New contributor
Garen Vartanian is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
2
  • "CORS will prevent the reading of sensitive data by malicious sites, but it will not prevent the posting of data to a server" - well, but it will. Browser will not allow sending a cross-domain POST request unless CORS allows this explicitly. "security needs redundancies (what if same-site policy is set to lax accident?) and additional server checks are important" - yep, maybe that's the reason. Unfortunately no one seems to know for sure and it's not documented ¯\_(ツ)_/¯ 2 days ago
  • I agree partially since most requests are sent with json content these days, but still with the caveat that an OPTION preflight request doesn't apply to simple POST requests (url-encoded etc. form submissions) and these can still go through to the server. It still falls on the server side to maintain some sort of auth. 2 days ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.