Is sending a cross-origin request from a browser and from a server any different?

I have started reading about CORS and wanted to understand how it works, SOP states that by default cross-origin requests are rejected by the server. So I have created two servers on localhost, one for port 8081, another one for 8082. The 8082 server looks like so:

const app = express();
//const cors = require('cors');
//app.use(cors({ origin: '*' }))

app.listen(8082, function () {
    console.log('server running on 8082')
})

app.get('/', (req, res) => {
    console.log({ host: req.headers.host })
    console.log({ origin: req.headers.origin })
    return res.json('good');
});

the 8081 looks like so:

const app = express();

app.use(express.static('public'))

app.listen(8081, function () {
    console.log('server running on 8081')
})

app.get('/request', (req, res) => {
    fetch('http://localhost:8082/').then(res => res.json()).then(console.log)

    return res.end();
});

Basically I just have the endpoint /request that tries to access the first server, aditionally besides the /request endpoint I have an index.html file which I serve, which is located at public directory and looks like so:

<script>
  function t() {
     fetch('http://localhost:8082/').then(res => res.json()).then(console.log)
  }
</script>
<button onclick="t()"></button>

It does absolutely the same as the /request endpoint, so what I do not understand , is why when I click the button and the request gets sent to the first server I receive a CORS error, but when I trigger the endpoint /request I receive a response without any CORS error displayed? Can someone explain this please?

Solution

if CORS can be bypassed by servers, why does it matter that CORS can not be bypassed by browsers

This statement contrasts browsers and servers in a false way.

The same-origin policy is a behavior that a user agent making HTTP requests implements in order to protect the user. And CORS is a protocol for limited exceptions to this policy. Users are in control of their user agent, and they can forgo that protection (by starting their browser with a command line option like --disable-web-security), but they are then responsible for the consequences.

In other words: Users can manipulate their browsers so that the same-origin-policy is bypassed, and they can manipulate their servers as they see fit. In both cases, the user is responsible

for the command line options they use with their browsers or
for the way they program their servers or for the libraries they use for making HTTP requests.

Why is there no same-origin policy/CORS on servers?

Two vulnerabilies that the same-origin policy is meant to protect users against are:

Users can be tricked into making unwanted requests with their browsers, for example, by clicking a link or loading a malicious image in a web mail reader.
When the browser makes a request, browser standards dictate that it silently inserts credentials that it knows of (see CSRF Tokens with separate API and Web Server). This leads to an authenticated request being made (although possibly unwanted by the user).

The same-origin policy and CORS rely on the concept of the origin in the browser's address bar. This concept is not applicable to servers, which have no address bar. There is therefore no such thing as a "cross-origin request from a server". Also, it would be much harder to trick users into making unwanted requests with a server on their computer. Or it would require much more gullible users who download and run untrusted programs.

To summarize: In order to protect themselves, users are advised not to disable the same-origin policy on their browsers and not to run servers on their computer that make arbitrary requests. But since the user is always in control of the HTTP client (whether that is a browser or a server), users cannot be prevented from ignoring this advice.