imagine you have your toys at home, and your friend wants to come and play with them. CORS is like asking your parents if it's okay for your friend to play with your toys.

​

Now, let's break it down:

​

Your Toys (Resources): In the computer world, websites and web applications have their toys, which are things like images, videos, or other data.

​

Your Friend (Another Website): Sometimes, another website wants to use or play with the toys on your website. Just like your friend coming over to play with your toys.

​

Asking Permission (CORS - Cross-Origin Resource Sharing): CORS is like asking for permission. Before your friend can play with your toys, they need your parents' approval. Similarly, when one website wants to use resources (toys) from another website, it needs permission, and CORS helps with that.

​

Permission Slip (HTTP Headers): Your parents may give your friend a special note (permission slip) that says it's okay to play with your toys. In the computer world, websites exchange special notes (HTTP headers) to say it's okay for another website to use their resources.

​

Let's look at a simple example:

​

Scenario:

​

Your toys (resources) are on website A (http://websiteA.com).

Your friend (another website) wants to use those toys on website B (http://websiteB.com).

Without CORS:

​

If there's no CORS, it's like your parents saying, "No, you can't take the toys to the other house!" The web browser (your parents) stops your friend from using the toys.

With CORS:

​

If there's CORS, it's like your parents saying, "Sure, you can take the toys, but only if you promise to bring them back." The web browser allows website B to use the toys from website A.

So, CORS is a way for websites to talk to each other and agree on whether it's okay to share toys (resources) or not. It helps keep the web safe and secure while allowing different websites to work together when needed.

Use CORS to allow cross-origin access. 

CORS is a part of HTTP that lets servers specify any other hosts 

from which a browser should permit loading of content.

​

How to block cross-origin access

To prevent cross-origin writes, 

    check an unguessable token in the request — known as a Cross-Site Request Forgery (CSRF) token. 

    prevent cross-origin reads of pages that require this token.

To prevent cross-origin reads of a resource, 

    ensure that it is not embeddable.

    prevent embedding because embedding a resource always leaks some information about it.

To prevent cross-origin embeds, 

    ensure that your resource cannot be interpreted

    Browsers may not respect the Content-Type header. 

For example, if you point a <script> tag at an HTML document, the browser will try to parse the HTML as JavaScript. When your resource is not an entry point to your site, you can also use a CSRF token to prevent embedding.

//Example

app.UseCors(x => x.AllowAnyHeader().AllowAnyMethod().WithOrigins("https://localhost:4200"));

There is this thing called CORS which stands for Cross Origin Resource Sharing. The page where swagger documentation is shown is fetched from our servers, but the swagger UI also needs to make calls to the server where the REST API is. This is a potential security risk, so browser wants to ask permission from the REST API server if it’s ok to use those resources (i.e. try out the API thru web UI swagger documentation)

​

If you want to make anything except a simple GET or there are any custom headers, the browser wants to make a preflight query to the back end. Browser wants to know if it’s ok to ask whatever it actually wants to ask. So the browser sends an OPTIONS method query to the back end passing along all the headers that the actual request will need. Sounds simple enough (yeah OK, it took me some time until I figured it out. I’m a bit slow) what can go wrong?

CORS => (Cross-Origin Resource Sharing) 

sharing resources between different sources