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.

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?

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.

No, the point of CORS is to mitigate against a security vulnerability in web browsers.

All non-browser based app needs no CORS setting

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.

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.

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.

> 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.

> SOP is a solution to a browser-specific security issue.

Indeed, it is, but in my opinion a pretty bad one as it causes a lot of collateral damage. Instead, they should just use the (cookie) state from the origin that initiates the request instead of the origin that receives the request. AFAIK, that should have solved the security issue much more precisely. But now we have to live with the SOP+CORS in the web based world :-/

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.

This. I suppose that's what has me confused about both the blog post and comment, i.e. why would you not control your servers?

Not entirely sure what parent meant but it seems that many web developers are still confused as to why they can't consume any site on the internet from the front end.

Because that is actually the classical pattern of applications using the internet ;-) The whole point of internet protocols like HTTP, SMTP and the likes is about not having control over the server and being able to let programs talk to each other anyway.

So if you want to build a classic client app it would be independent from the server implementation. So maybe it would even be 'your' that you would use. For example you could built an app that could talk to a Dropbox server. But with the current SOP setup you would require Dropbox to configure their CORS accordingly.