Cross-Origin Resource Sharing (CORS) is a browser rule that decides whether a page loaded from one website is allowed to read data from a different website. By default browsers block these cross-domain requests, and CORS is the controlled way a server says “yes, this specific site is allowed”.
Think of a members-only club. Your browser holds your membership card, but the club still checks a guest list before letting an outside request walk in with it. When a page on shop.example.com tries to fetch from api.payments.com, the browser asks the payments server, in effect, “is shop.example.com on your list?” The server answers with an HTTP header called Access-Control-Allow-Origin. If your site is named there, the data flows; if not, the browser blocks it and you see the familiar “blocked by CORS policy” message.
For certain requests the browser checks first with a small “preflight” call using the OPTIONS method, asking permission before it sends the real request. This is why a request that includes a custom header or a method like DELETE can fail even when a plain GET works fine: the server has to allow those too. And remember the limit of what CORS does. It governs whether a browser hands the response back to JavaScript, not whether the server runs the request, so it is never a replacement for real authentication.
This is why CORS trips people up. The error appears in the browser, but the setting that fixes it lives on the API you are calling. If you own that API you add your domain to the allowed list; if a third party runs it, you ask them to allow you.
At TopDevs we configure CORS deliberately on the APIs we build, allowing exactly the domains a client needs and nothing more, so integrations work without quietly opening a door to everyone else.
