• Home
    • How-to guides
    • Snippets
    Cheatsheets:LinuxGitBckgrnd

CORS

September 07, 2021

post-bg

Content
– CORS & Headers
– JSONP before CORS becoming the standard
– Preflight requests

Cross-origin resource sharing

Defines how the browser and server must commnunicate when accessing resources across origins. It allows scripts running on a browser-client to interact with resources from a different origin in a secure manner. In other words, CORS allows you to use resources from other sites in your site; which normally thanks to SOP - same origin policy - you wouldn't be able to.

SOP or same origin policy prevents you from making Ajax requests outside the origin location where the script is running. This is strictly done for security purposes, if you're accessing your bank data on a page for example, you wouldn't want anyone to be able to access the DOM in this page and be able to view this page's data in another page.

Prevented by SOP

cors

The third call wouldn't be allowed by the browser since these are different origins. One approach is to do this via a proxy - server-to-server; however not quite the same thing. A technique commonly used as a work-around before CORS becoming the new standard was JSONP, and it involved passing data back into a callback function. The server would wrap some JSON data in a JS function call, then in the browser's webpage, a new script tag would be created with the callback's function name, that the browser would then load, parse and execute dynmically.

Simple CORS request with headers

JSONP only works for GET methods and it is a hack around SOP. CORS in the other hand it is the new starndard - supported by all major browsers - that defines the rules by which a browser may allow from different origins in a secure manner.

GET/POST and HEAD requests with body text/plain are considered simple CORS requests. We then add an origin header to the request, that includes protocol, domain name, and pageName, that would look like this:

Origin: https://kcosa.com/pageName/

What follows the cross-origin request above is the server response, that must include this headings:

Access-Control-Allow-Origin: https://kcosa.com   //or
Access-Control-allow-Origin: *

Preflight requests (OPTIONS)

pre-flight

Request headers

The pre-flight request is an OPTIONS requests as opposed to GET, POST, and PUT, and it has a few more headers in it.

Request header Description
Origin The origin is the domain with scheme that's the HTTP or HTTPS of the page that's making the request.
Access-Control-Request-Method Access-Control-Request-Method is the method that the browser wants to use: GET, POST or PUT
Access-Control-Request-headers Access-Control-Request-headers are the headers that the browser wants to use.

Response headers

Once the browser has received the response from the server, it will cache it for that URL, and it will determine whether it's a valid request or not and it'll proceed accordingly.

Response header Description
Access-Control-Allow-Origin Access-Control-Allow-Origin is the origin that should be allowed
Access-Control-Allow-Methods Access-Control-Allow-Methods are the methods that are allowed
Access-Control-Allow-Headers Access-Control-Allow-Headers are the headers that can be passed
Access-Control-Max-Age Access-Control-Max-Age, how long it might be valid for
Access-Control-Allow-Credentials Access-Control-Allow-Credentials HTTP off credentials and cookies
  • Terms & Conditions
  • kcosa.com © 2025
  • Privacy Policy