Thread by @isocroft

Having problems with #CORS (Cross Origin Resource Sharing) almost every time ?
Wondering why you mostly always run into a blocked request ?

Remember that it's all about 3 rules that aren't mutually exclusive.

I'll be writing about them in 10 mins time (don't miss it)

#Thread

What is CORS ?

Simply defined as a access control security restriction that is used to limit cross-domain communication based on the origin of a web site or app.

The key word here is Access Control - which is about authorization of http requests

#Thread \1

Another key word is Origin: the origin is based off a combination of 2 things

1. A Scheme /Protocol( http / https )
2. A Host/Sub+Top Level Domain ( google.com )

Ok ? Cool!

Now you ask

How does this CORS thing actually work ?

#Thread \2

When a site makes a request to another site

e.g. accounts.google.com ---> makes request to ----> mail.google.com. How is that request handled ?

Well the first question to ask: is this a cross domain request or not ?

Yes... It's a cross domain request

#Thread \3

How ? Well, in as much as the Scheme/Protocol is the same ( https ), the Host isn't exactly the same

1. accounts.google.com
2. mail.google.com

"accounts" and "mail" are not the same

But just because it's cross domain doesn't mean it will be CORS worthy

#Thread \4

CORS worthy means that the restrictions will be triggered based on the origin of the web request which also means that the request has the potential to be blocked.

If you don't pick up any other thing from this #Thread, Just remember that:

#Thread \5

NOT ALL CROSS DOMAIN REQUESTS AUTOMATICALLY TRIGGER RESTRICTIONS

Why ? Because being a cross domain is not enough to trigger restrictions

There are as i said earlier 3 rules which you must keep in mind.

#Thread \6

Any time at least one of this rules is broken, then you can be certain that the restrictions can be triggered or there can be the possibility of a blocked request

RULE 1:

The request is not a GET, HEAD or POST

Simple and straight-forward huh ? Yeah!!

#Thread \7

So, when the request is cross domain based on the origin and the request method is not GET, HEAD or POST. then know that the CORS restriction may likely be triggered.

When CORS is triggered, an OPTIONS (pre-flight) request is fired first before the main request.

#Thread \8

The pre-flight request starts off a chain of exchanges (http headers: request & response ) between the browser and the server.

Access-Control-Request-* request headers
Access-Control-Allow-* response headers

We'll talk more about these exchanges in detail later on.

#Thread \9

RULE 2:

If the request method is not GET or HEAD and includes a
"Content-Type" request header. The Content-Type header value is not any of these 3 values

1. text/plain
2. application/x-www-form-urlencoded
3. multipart/form-data

So what this means in a nutshell is that if you use a HTML Form ( #enctype equalling of any of the 3 mime types above) to make a cross domain request, you will NEVER trigger a restriction or a potential request block

#Thread \11

Also, Since Content-Type for graphql requests is either

1. application/json
2. application/graphql

As opposed to

1. application/x-www-form-urlencoded
2. multipart/form-data
3. text/plain

#Thread \12

This clearly means that graphql requests will ALWAYS trigger a restriction or potential request block too (a.k.a OPTIONS requests will be made before the main http request)

RULE 3:

Special/Custom request header(s) like "Authorization" or "X-Requested-WIth" is set

#Thread \13

If you have an "Authorization" request header set in your request and the request method is POST and the request is cross domain request and "Content-Type" is "multipart/form-data", it will still trigger a CORS restriction.

It means that all 3 rules MUST be obeyed!

#Thread \14

If you do find yourself in a situation where a CORS restriction is triggered and you get that "annoying" error in the browser console. There are a few things to do on both the browser and the server

#Thread \15

The first thing is to start off on the server and setup which Origin(s) you wish to allow if you have control over the server OR find out which Origin(s) are allowed if you don't have control over the server

Then, setup the right Access-Control HTTP request headers

#Thread \16

Firstly, the browser always sets up Origin request header which will be used to identify the requester. if the server is setup for CORS, the server responds with a Access-Control-Allow-Origin response header. No OPTIONS request is triggered and everything works

#Thread \17

If you have custom HTTP request headers set, then you may need to inform the server to "allow" them

For example:

http-request-from-browser:
Access-Control-Request-Headers: Authorization

http-response-from-server:
Access-Control-Allow-Headers: Authorization

#Thread \18

@threadreaderapp unroll