browsers enforce a rule called the "same-origin policy" which stops Javascript code from being able to make arbitrary HTTP requests
these are why the same-origin policy is important
company.com/page.html) or the address of the script (like somecdn.com/yourscript.js)? that's part of why it's so important to only include Javascript from sources you trust in your webpages.
https://website.com/apple, is a request to https://subdomain.website.com a same-origin request? the domain and subdomain need to be exactly the same
http://website.com/apple, is a request to http://website.com/banana a same-origin request? if the domain/subdomain, port, and protocol (http / https) are the same, it's the same origin!
embedding Javascript, CSS, and images from origins is always allowed, as well as some POST requests (like form submissions).
But, for example, making an arbitrary
GET request to an HTTP API isn't. there are some forbidden headers you're never allowed to set, like Content-Length and Host. But otherwise you can send any request you want.
api.yourstore.com from the origin yourstore.com? Access-Control-Allow-Origin: yourstore.com header on the HTTP response! for a basic cross-origin GET request, the browser actually will send the GET request, but it won't allow the Javascript to read the response unless the response has the right header.
It's usually better to allow a allowlist of specific origins and not *.
api.yourstore.com from a different origin? OPTIONS request with the right headers! If you're making a cross-origin POST request with some JSON, the browser won't even send the request by default. Instead, it'll send a "preflight" OPTIONS request and check the response headers.
if this were possible, it would let any attacker get around the same-origin policy just by setting a request header in their request. The server needs to be the one to allow the request.