5 ms·

For non-browser apps the server doesn't have to explicitly allow it. A simple curl can access any server it wants. If y browser based apps wants to access anoth

For non-browser apps the server doesn't have to explicitly allow it. A simple curl can access any server it wants. If y browser based apps wants to access another server, that server needs to be configured to allow it (because of the Same Origin Policy) and how many servers do you know that allow anybody to access them via CORS? So take for example a WebDAV server. In theory, you could build a web based app, that can access any WebDAV server out there on the internet. In practice, that WebDAV server requires a special CORS configuration in order to be accessible via a browser from a different origin. Any other normal desktop app doesn't care about CORS and can access any server it has credentials for, no matter what configuration it has.

Cederfjard 6y ago
Not all apps need to contact third-party servers, so the way you categorically claim that building cross site web apps is next to impossible seems a bit exaggerated? Edit: Unless you don’t consider it ”cross site” if you control the API server?
kreetx 6y ago
I would think any service that wants to be consumed will have CORS configured? All else should be forbidden, that is the whole point of CORS.
- rk06 6y ago
  No, the point of CORS is to mitigate against a security vulnerability in web browsers. All non-browser based app needs no CORS setting
  - kreetx 6y ago
    No ;), the point of CORS is to open up the web for cross-origin consumption from the browsers by allowing servers/services to opt in with special headers. Single origin policy is the one that protected against cross-origin requests and is still the default when no CORS is in place.
    - arendtio 6y ago
      You are missing the point. You are right about SOP vs. CORS, but the point is, that most clients that are no browsers have no SOP and therefore also don't care about CORS. So every server, that is not specifically designed to accept connections from browsers, cannot be reached by browser based apps. And that in turn is a serious disadvantage for these apps, because it eliminates a complete class of use-cases. Yes, if you control both ends you can make it possible, but if you want to build an app that is able to simply connect to any server out there, you will be in trouble.
      - kreetx 6y ago
        Let's try to get to the point then! Any server not configured to reply with permissive CORS headers doesn't want to handle your cross-origin requests. I.e they are not "public areas" for anyone to consume but serve just their own front end. CORS is a security measure to make it safe to consume cross-origin servers from browsers, both with and without credentials. Otherwise, with credentials you could read client data for some other service. and without credentials you could just use that service's resources without having permission. CORS gives the service operator a method to give permission. Querying other servers from your back end is another story entirely. CORS isn't required there but also, your server doesn't have access to any of the credentials available in the browser so you wouldn't be able to get any client-specific data. You can get any other data of course, but because this is a server it's easier to block, perhaps by IP or adding captcha.
      - dragonwriter 6y ago
        > You are right about SOP vs. CORS, but the point is, that most clients that are no browsers have no SOP and therefore also don't care about CORS. Clients that aren’t browsers don’t generally have access cookies or similar user credentials for third party services as a result of user interaction with those services that allow exfiltration of data without user intent in the absence of SOP. SOP is a solution to a browser-specific security issue.
        arendtio 6y ago
layoutIfNeeded 6y ago
Well, WebDAV clients don’t usually run untrusted scripts downloaded from random servers, so they don’t need CORS. In this sense (i.e. running dubious scripts from random untrusted sources) the closest thing to browsers would be npm, although its centralized nature (mostly) prevents malicious actors causing too much damage.

Cederfjard 6y ago

Not all apps need to contact third-party servers, so the way you categorically claim that building cross site web apps is next to impossible seems a bit exaggerated? Edit: Unless you don’t consider it ”cross site” if you control the API server?

kreetx 6y ago

I would think any service that wants to be consumed will have CORS configured? All else should be forbidden, that is the whole point of CORS.

rk06 6y ago
No, the point of CORS is to mitigate against a security vulnerability in web browsers. All non-browser based app needs no CORS setting
- kreetx 6y ago
  No ;), the point of CORS is to open up the web for cross-origin consumption from the browsers by allowing servers/services to opt in with special headers. Single origin policy is the one that protected against cross-origin requests and is still the default when no CORS is in place.
  - arendtio 6y ago
    You are missing the point. You are right about SOP vs. CORS, but the point is, that most clients that are no browsers have no SOP and therefore also don't care about CORS. So every server, that is not specifically designed to accept connections from browsers, cannot be reached by browser based apps. And that in turn is a serious disadvantage for these apps, because it eliminates a complete class of use-cases. Yes, if you control both ends you can make it possible, but if you want to build an app that is able to simply connect to any server out there, you will be in trouble.
    - kreetx 6y ago
      Let's try to get to the point then! Any server not configured to reply with permissive CORS headers doesn't want to handle your cross-origin requests. I.e they are not "public areas" for anyone to consume but serve just their own front end. CORS is a security measure to make it safe to consume cross-origin servers from browsers, both with and without credentials. Otherwise, with credentials you could read client data for some other service. and without credentials you could just use that service's resources without having permission. CORS gives the service operator a method to give permission. Querying other servers from your back end is another story entirely. CORS isn't required there but also, your server doesn't have access to any of the credentials available in the browser so you wouldn't be able to get any client-specific data. You can get any other data of course, but because this is a server it's easier to block, perhaps by IP or adding captcha.
    - dragonwriter 6y ago
      > You are right about SOP vs. CORS, but the point is, that most clients that are no browsers have no SOP and therefore also don't care about CORS. Clients that aren’t browsers don’t generally have access cookies or similar user credentials for third party services as a result of user interaction with those services that allow exfiltration of data without user intent in the absence of SOP. SOP is a solution to a browser-specific security issue.
      - arendtio 6y ago

layoutIfNeeded 6y ago

Well, WebDAV clients don’t usually run untrusted scripts downloaded from random servers, so they don’t need CORS. In this sense (i.e. running dubious scripts from random untrusted sources) the closest thing to browsers would be npm, although its centralized nature (mostly) prevents malicious actors causing too much damage.