If your company hosts content on https://company-news.corp.internal/ it’s very important that some random malicious site on the internet can’t use fetch() or XMLHttpRequest to read that page and exfiltrate that information, just from one of your employees being tricked into visiting that site.
So it’s about more than just cookies.
There is a case to make for old protocols and stuff Microsoft just won't fix (it's always Microsoft). But segmenting a web intranet because you expect the information not to escape is doubly stupid. It not only will escape through an infinity of exploits that exist everywhere; you have exactly 2 groups of people to make access control over, what it certainly insufficient; and finally, you constraint the capacity of people to work physically to inside your office.
It's one layer in the security stack. It's not sufficient on it's own but there's no reason to get rid of it because it's not 100% effective.
> you constraint the capacity of people to work physically to inside your office.
Or, you know, just have a VPN.
Or perhaps the client can tell the server what webpage it's fetching from and the security check can be done server-side?
It is just strange to me that this security check has to be done on client-side (in the browser) as opposed to on the web server actually responsible for distributing the content.
Because people are lazy or they may forget to implement the security checks, or simply be unaware about them.
Ex., when you hacked up a super simple script to display a number of today's users of your startup to display on the big screen in your office. You would probably want something as simple as possible. This page is just 3-5 lines of code. Maybe one-liner even. No authorization or other security, as it's for the office intranet.
Without CORS any website that is visited by people from your office could fetch that number on screen.