Unfortunately what you are trying to do is effectively impossible because HTTP simply was not intended for this use case. I think there are a few misunderstandings that are confusing the issue for you. Running through things:
- There is nothing special about browsers. Browsers are just a fancy HTTP client that can send HTTP requests to an HTTP server. However, they are not the only HTTP clients that can send requests to a server. If you have ever made HTTP requests from your own server, you are already aware of this. Similarly tools like postman, curl, etc, are also HTTP clients and can make HTTP requests to your server, except they are not "running" on a domain anywhere.
- In fact the whole question of "what domain is making this request?" is a concept that doesn't exist in HTTP. It's easy to misunderstand this fact because of how CORS works, but CORS is something that is baked into browsers - not HTTP. CORS is only meant to protect HTTP requests made by javascript on a webpage inside a browser (again, it's not strictly part of HTTP). As a result if you put up a completely restrictive CORS policy banning access from everywhere except your main domain, that CORS policy would do absolutely nothing if someone visited your API endpoint from literally any other HTTP client - which is what you just discovered. Anyone using postman, curl, etc would still be able to access your API endpoints without issue, regardless of what CORS says, because CORS only matters for browsers.
- Blocking by domain is impossible because HTTP doesn't know anything about domains. When a client makes an HTTP request it first uses a DNS service (if needed) to convert the domain name of the destination into an IP address. The client then sends its HTTP request to that IP address. The only thing the server knows is the IP address of the client. All other information is provided by the client and can therefore be easily spoofed by an attacker. I say this because while some browsers may attach information to the HTTP request stating what domain the javascript that made the request is running on, a non-browser client can easily do the same and lie, claiming to be javascript running on your domain.
In short the only thing the server knows is the IP address of the client (technically that can be spoofed to, but it is substantially more difficult). All other information about the request is provided by the client and therefore cannot be trusted for security purposes.
It may help to brush up on the basics of HTTP. The details in that link break things down well. The link also happens to focus on browsers as the HTTP client, which we know is not exclusively true. Ironically articles like that one are why misconceptions like yours are common :) Still, with a proper understanding that HTTP clients can be anything, that link should be helpful.
This doesn't answer how to secure your endpoints. I can't give you an answer there without more details, which would basically make this a new question (aka you'd be better off asking a new question than editing this one, I think). In general there are lots of strategies, but the short of it is that you can't have an anonymous endpoint and also selectively block users, except by IP address (which isn't possible for endpoints that are supposed to be accessed from a browser). As a result there is only one general answer: you need to put some kind of authentication on the endpoint, even if it doesn't specifically require a login.
