I think it once was a common design pattern to have static HTML with a form that was submitted to a different server on a different domain, or at least a different protocol. For example, login forms served over HTTP were common, but the actual POST request was sent over HTTPS (which at least hid the username/password from passive observers). When Javascript added the capability to perform client-side form validation, it inherited this cross-domain POST capability.

I don't know why <script> has the ability to perform cross-domain reads (the exception to the not-able-see-the-response rule). I doubt anyone had CDNs with popular Javascript on their minds when this was set in stone.

>I don't know why <script> has the ability to perform cross-domain reads

That's because all scripts loaded on the page are operating in the same global namespace of the same javascript vm, which has origin of the page. Since there are no contexts granularity below the page level in VM, they have to either share it or not work.

You can't read it however, you can ask browser to execute, the same way you can ask it to show an image. It's just execution can have result in a read as side-effect by calling a callback or setting well-know global variable

What I meant is that from a 1996 perspective, I don't see a good reason not to block cross-domain <script> loads. The risks must have already been obvious at the time (applications serving dynamically generated scripts that can execute out of origin and reveal otherwise inaccessible information). And the nascent web ad business had not yet adopted cross-domain script injection as the delivery method.

There is no reason for browser to block them if the page is static and written by hand. If I added this script to my page, then I want to do the funny thing and if the script misbehaves, I remove it.

Are you talking about the risk from inclusion to the including page? The concern about cross-origin requests was in the other direction (to the remote resource, not the including page). That concern applies to <script> inclusion as well, in addition to the possibility of running unwanted or incompatible script code.

Yes, I was talking about the risk from the perspective of the including page. From the perspective of the risk to remote it makes even less sense from the 90ies point of view. Data isn't supposed to be in javascript anyway, it should be in XML. It's again on you (the remote) if you expose your secrets in the javascript that is dynamically generated per user.

With a hindsight from this year -- of course you have a point.

Ahh, the data-in-XML argument is indeed very convincing from a historic perspective.

XHR is called xmlthttprequest for a reason, but that was added in 2000ies I think. SOAP was late 90ies, but I don't think you can call it from browser. There was no reason to have data in javascript before DOM and XHR which were late additions. All the stuff was in the page itself rendered by server and you don't get that across the domain boundary.

> 2000ies

Now this is interesting. I've seen a lot of "40ties", "90ies", etc around, and I'm not sure why people do that. But once you've done it, it's clear how to read the text. Most of the non-numeric suffix is redundant; people mean "forties", not "forty-ties".

But "2000ies" has no potential redundancy and no plausible pronunciation. It's spelled as if you're supposed to pronounce it "two thousandies", but there's no such thing as a thousandy.

I enjoyed your analysis.

I think people should really just be putting 's on the end, then it works for all:

40's, 50's, 2000's.

The apostrophe is unecesary, but IMO without it it looks like the 's' is a standard unit of measurement:

40s, 50s, 2000s

twothousandies and twenty-zeroes makes sense

The point being, presumably, the page author explicitly chose to include a cross-domain script

The script author however didn't. CORS is more about the remote giving consent to exfiltrate the data than it is about preventing injecting the data into it. You can always reject the data coming in

The threat model of one site leveraging the user's browser to covertly and maliciously engage with a third-party site was something that emerged and matured gradually, as was the idea that a browser was somehow duty-bound to do something about it.

Browsers were just software that rendered documents and ran their scripts, and it was taken for granted that anything they did was something the user wanted or would at least hold personal responsibility for. Outside of corporate IT environments, users didn't expect browsers to be nannying them with limitations inserted by anxious vendors and were more interested in seeing new capabilities become available than they were in seeing capabilities narrowed in the name of "safety" or "security".

In that light, being able to acccess resources from other domains adds many exciting capabilities to a web session and opens up all kinds of innovate types of documents and web applications.

It was a long and very gradual shift from that world to the one we're in now, where there's basically a cartel of three browser engines that decide what people can and can't do. That change is mostly for the best on net, when it comes to enabling a web that can offer better assurances around access to high-value personal and commercial data, but it took a while for a consensus to form that this was better than just having a more liberated and capable tool on one's computer.

You still can make many kinds of requests [0] to an arbitrary endpoint that isn't the page origin, without being able to see the response. (Basically, anything that a <link> or a form submission could do.) And you can't include any cookies or other credentials in the request unless they have SameSite=None (except on ancient browsers), and if you do, then you still can't see the response unless the endpoint opts in.

Really, there's exactly one thing that the mandatory CORS headers protect against: endpoints that authorize the request based on the requester's IP address and nothing else. (The biggest case of this would be local addresses in the requester's network, but they've been planning on adding even more mandatory headers for that [1].) They don't protect against data exfiltration, third-party cookie exfiltration (that's what the SameSite directive is for), or any other such attack vector.

[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...

[1] https://wicg.github.io/private-network-access/

Yes I know this is still the case today. My question is: how did this come about? It seems to me that in the olden days the idea of cross origin requests wasn’t really needed as you’d be lucky to have your own domain name, let alone make requests to separate services in an era of static HTML pages with no CSS or JavaScript. What exactly was this feature for? Or was it not a feature and just an oversight of the security model that got codified into the spec?

The field of web applications didn’t really blow open until we were into the DotCom era. By then Berners-Lee’s concept for the web was already almost ten years old. I think it’s hard for people to conceive today what it was like to have to own a bookshelf of books in order to be a productive programmer on Windows, for instance. Programming paradigms were measured literally in shelf-feet.

Practically part of the reason Java took off was it was birthed onto the Internet and came with Javadoc. And even then the spec for Java Server Pages was so “late” to the party that I had already worked on my first web framework when the draft came out, for a company that was already on its second templating engine. Which put me in rarified air that I did not appreciate at the time.

It was the Wild West and not in the gunslinger sense, but in the “one pair of wire cutters could isolate an entire community” sense.

Hotlinking <img>s from other domains has been a thing forever, as far as I'm aware, and that's the archetypical example of a cross-origin request. <iframe>s (or rather, <frame>s) are another old example. And it's not like those would've been considered a security issue, since at worst it would eat up the other domain's bandwidth. The current status quo is a restriction on what scripts are allowed to do, compared to those elements.

By definition those do allow you to see the response so that’s not really what is being discussed.

Not really. You as an application generally can't read across origin boundaries, but you can ask browser to show it to the user.

That makes perfect sense in the early model of internet where everything was just links and documents. You can make an HTML form with action attribute pointing to a different domain. That's a feature, not a bug and isn't a security vulnerability in itself. Common use for this is to make "search this site in google" widgets.

Then you can make the form make post requests by changing a method. Nothing wrong with this either -- the browser will navigate there and serve the page to user, not to the origin server.

What makes it problematic is the combination of cookies from the destination domain and programmatic input or hidden field from the origin domain. But the only problem it can cause is the side-effects that POST request causes on the back end, as it again doesn't let the origin page to read the result (i.e. content doesn't cross the domain boundary).

Now in the world on JS applications that make requests on behalf of the user without any input and backend servers acting on POST requests as user input, the previously ignored side-effects are the main use and are a much bigger problem.

"search this site in google" shouldn't even be a POST request, but yeah, when we'll have better defaults for cookies it should work nicer. And if you are a web developer, you should check your session cookie attributes and explicitly set them to SameSite=Lax HttpOnly unless your frameworks does that already and unless you know what you're doing

It was GET request, but the point is -- you can make the request from the browser to a different domain by making a form. With JS and DOM you can make a hidden iframe and make the request without user initiating it or noticing even, but in both cases you don't get to read the result.

I don’t have a Time Machine or a 1998-era browser but I’m not sure what you described was the case. I think in the before times, a browser could send a request to any arbitrary endpoint that was not the page origin, and it could also see the response. I might be wrong.

But anyway, ancient history.

Wikipedia references this part of the Netscape Navigator documentation: https://web.archive.org/web/20020808153106/http://wp.netscap...

This suggests that the same-origin policy was introduced rather quickly after the introduction of Javascript, as a security fix.

I think you might have forgotten how immature the field of computer security, especially for network applications, was in the 90s/00s. This was the era of register_globals in PHP, CGI scripts written in C, HTTPS being some fancy luxury for banks and OS login dialogs you could kill with task manager.