5

I am confused about why websites use CORS. I know CORS provide some protocols through which website can call the resources from other domains, but is it possible to call the resource without CORS?

If it is, then what vulnerability can it cause?

1
  • CORS lets browsers do the same thing as curl or php, within the spec.
    – dandavis
    Sep 19, 2017 at 19:36

2 Answers 2

1

You can send GET and POST requests cross domain even if the target does not use CORS, but there are some restrictions. Most importantly, you can not read the response. This restriction is built into browsers as part of the Single Origin Policy (SOP) and it protects against data leaking across domains. However, it also stops you from publiching an API that can be read from any domain.

CORS gives you the option to remove that restriction, i.e. allowing the domain that is hosting the API to announce to browsers that it allows cross domain calls from either all or some domains. So I wouldn't say CORS is protecting against a specific vulnerability. Rather it allows you to open your API:s up to the world. Not having a CORS policy at all will always be the most restrictive option.

For more reading on CORS I recommend Mozilla and HTML5 Rocks.

7
  • By reading your answer i got that, browser set the SOP automatically. Sep 19, 2017 at 12:40
  • can you please define the work of the img src in the html page, I mean when you got to the source code in the website and you see their are lot of img src and script src files there, so how they work.? And i think they work without CORS? So can you plz define it, I hope you get my point.. ;) Sep 19, 2017 at 12:44
  • An ordinary GET request for an image requires no CORS. But if foo.com/index.html includes the image bar.com/image.png, Foo can not read the content of the image. Sure, it is displayed, but the browser will not let Foo read the content using e.g. getImageData.
    – Anders
    Sep 19, 2017 at 13:33
  • Okay its interesting to ask you question so this is last one :P, i have read about how to abuse the CORS, but i want to know in the Real world CORS abusing, i mean when attacker changes the origin header let's say example.com to attacker.com , if the origin header (attacker.com) is reflected back then that's it, attacker now read out the contents of the web page. Is this how we can abuse this? Sep 19, 2017 at 13:48
  • No, you can't abuse it that way. The browser will not let you change the origin header. Sure, you could do it on your own computer with curl or something, but that would be pointless since you wouldn't have access to the victims cookies etc.
    – Anders
    Sep 19, 2017 at 13:52
-1

Anders answer is technically correct that CORS is to relax restrictions imposed by Single Origin Policy (SOP) according to some web site configuration.

To expand on that, the main point of SOP is to prevent Cross Site Request Forgery (CSRF) attacks based on javascript requests (see remark at the bottom). And CORS is to allow some cross origin requests without opening up to CSRF attacks.

i.e. prevent a malicious site making client browser perform operations on a sensitive site client is already logged in to.

For example client opens cute-kitties.malicious.example.com and some javascript on that site makes request to paymepal.example.com with client already being signed into paymepal.example.com

With CORS, such requests will be blocked by browser... unless paymepal.example.com is configured to allow CORS with credentials and the desired methods for requests with origin cute-kitties.malicious.example.com

P.S. SOP and CORS are only part of the defense related to javascript requests, see the linked OWASP CSRF page to see an extensive description how to fully protect from that class of attack.

7
  • the main point of SOP is to prevent Cross Site Request Forgery (CSRF) attacks [...] No...
    – jub0bs
    Dec 19, 2021 at 16:49
  • @jub0bs, would you be so kind to tell what is it then? Dec 20, 2021 at 12:39
  • I don't have to. It's plainly laid out on developer.mozilla.org/en-US/docs/Web/Security/…: Cross-origin writes are typically allowed. Some CSRF attacks may very well involve only simple (i.e. not preflighted) requests, and the SOP will happily let such requests through. Claiming that the main point of the SOP is to prevent CSRF is misleading. Rather, the main objective of the SOP is to cross-origin reads.
    – jub0bs
    Dec 20, 2021 at 14:57
  • To be clear: The purpose of a CSRF attack is to get a victim to send a request that will result in some state-changing action (write) on the server side; the purpose of the attack isn't to read the response to that request from the attacker's origin.
    – jub0bs
    Dec 20, 2021 at 15:01
  • @jub0bs, from developer.mozilla.org/en-US/docs/Web/Security/… The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin. Interaction doesn't mean only read or write. Tell me please what is the main mechanism in browser to prevent CSRF if this is not SOP? Dec 20, 2021 at 19:06

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.