How does Access-Control-Allow-Origin header work

Question

Apparently  I have completely misunderstood its semantics  I thought of something like this    A client downloads javascript code MyCode js from http   siteA - the origin  The response header of MyCode js contains Access-Control-Allow-Origin  http   siteB  which I thought meant that MyCode js was allowed to make cross-origin references to the site B  The client triggers some functionality of MyCode js  which in turn make requests to http   siteB  which should be fine  despite being cross-origin requests    Well  I am wrong  It does not work like this at all  So  I have read Cross-origin resource sharing and attempted to read Cross-Origin Resource Sharing in w3c recommendation  One thing is sure - I still do not understand how am I supposed to use this header    I have full control of both site A and site B  How do I enable the javascript code downloaded from the site A to access resources on the site B using this header   P S   I do not want to utilize JSONP

User · Answer

Using React and Axios  join proxy link to the URL and add header as shown below  https   cors-anywhere herokuapp com    Your API URL  Just by adding the Proxy link will work  but it can also throw error for No Access again  Hence better to add header as shown below   axios get  https   cors-anywhere herokuapp com  YOUR API URL    headers    Access-Control-Allow-Origin                 then response   gt  console log response data           WARNING  Not to be used in Production     This is just a quick fix  if you re struggling with why you re not able to get a response  you CAN use this    But again it s not the best answer for production       Got several downvotes and it completely makes sense  I should have added the warning a long time ago

User · Answer

Question is a bit too old to answer  but I am posting this for any future reference to this question   According to this Mozilla Developer Network article      A resource makes a cross-origin HTTP request when it requests a resource from a different domain  or port than the one which the first resource itself serves      An HTML page served from http   domain-a com makes an  lt img gt  src request for http   domain-b com image jpg  Many pages on the web today load resources like CSS stylesheets  images and scripts from separate domains  thus it should be cool    Same-Origin Policy  For security reasons  browsers restrict cross-origin HTTP requests initiated from within scripts  For example  XMLHttpRequest and Fetch follow the same-origin policy  So  a web application using XMLHttpRequest or Fetch could only make HTTP requests to its own domain   Cross-Origin Resource Sharing  CORS   To improve web applications  developers asked browser vendors to allow cross-domain requests   The Cross-Origin Resource Sharing  CORS  mechanism gives web servers cross-domain access controls  which enable secure cross-domain data transfers  Modern browsers use CORS in an API container - such as XMLHttpRequest or Fetch - to mitigate risks of cross-origin HTTP requests   How CORS works  Access-Control-Allow-Origin header   Wikipedia      The CORS standard describes new HTTP headers which provide browsers and servers a way to request remote URLs only when they have permission       Although some validation and authorization can be performed by the server  it is generally the browser s responsibility to support these headers and honor the restrictions they impose    Example   The browser sends the OPTIONS request with an Origin HTTP header    The value of this header is the domain that served the parent page  When a page from http   www example com attempts to access a user s data in service example com  the following request header would be sent to service example com   Origin  http   www example com The server at service example com may respond with    An Access-Control-Allow-Origin  ACAO  header in its response indicating which origin sites are allowed  For example     Access-Control-Allow-Origin  http   www example com An error page if the server does not allow the cross-origin request An Access-Control-Allow-Origin  ACAO  header with a wildcard that allows all domains   Access-Control-Allow-Origin

User · Answer

In Python I have been using the Flask-CORS library with great success  It makes dealing with CORS super easy and painless  I added some code from the library s documentation below    Installing     pip install -U flask-cors   Simple example that allows CORS for all domains on all routes   from flask import Flask from flask cors import CORS  app   Flask   name    CORS app    app route      def helloWorld      return  Hello  cross-origin-world     For more specific examples see the documentation  I have used the simple example above to get around the CORS issue in an ionic application I am building that has to access a separate flask server

User · Answer

i work with express 4 and node 7 4 and angular I had the same problem me help this   a  server side  in file app js i give headers to all response like   app use function req  res  next            res header  Access-Control-Allow-Origin   req headers origin         res header  Access-Control-Allow-Headers    Origin  X-Requested-With  Content-Type  Accept          next             this must have before all router  I saw a lot of added this headers   res header  Access-Control-Allow-Headers        res header  Access-Control-Allow-Credentials   true   res header  Access-Control-Allow-Methods    GET PUT POST DELETE      but i dont need that  b  client side  in send ajax you need add   withCredentials  true   like    http        method   POST        url   url        withCredentials  true       data            then function response              code         function  response                code           good luck

User · Answer

Nginx and Appache As addition to apsillers answer I would like to add wiki graph which shows when request is simple or not  and OPTIONS pre-flight request is send or not   For simple request  e g  hotlinking images  you don t need to change your server configuration files but you can add headers in application  hosted on server  e g  in php  like Melvin Guerrero mention in his answer - but remember  if you add full cors headers in you server  config  and at same time you allow simple cors on application  e g  php  this will not work at all  And here are configurations for two popular servers  turn on CORS on Nginx  nginx conf file   x000D   x000D  location     index  php                   add header  Access-Control-Allow-Origin    http origin  always    if you change   http origin  to     you shoud get same result - allow all domain to CORS  but better change it to your particular domain      add header  Access-Control-Allow-Credentials   true  always      if   request method   OPTIONS            add header  Access-Control-Allow-Origin    http origin     DO NOT remove THIS LINES  doubled with outside  if  above          add header  Access-Control-Allow-Credentials   true           add header  Access-Control-Max-Age  1728000    cache preflight value for 20 days         add header  Access-Control-Allow-Methods   GET  POST  OPTIONS      arbitrary methods         add header  Access-Control-Allow-Headers   My-First-Header My-Second-Header Authorization Content-Type Accept Origin     arbitrary headers         add header  Content-Length  0          add header  Content-Type   text plain charset UTF-8           return 204          x000D   x000D   x000D    turn on CORS on Appache   htaccess file   x000D   x000D    ------------------------------------------------------------------------------     Cross-domain Ajax requests                                                     ------------------------------------------------------------------------------    Enable cross-origin Ajax requests    http   code google com p html5security wiki CrossOriginRequestSecurity   http   enable-cors org     change    allow any domain  below to your domain Header set Access-Control-Allow-Origin     Header always set Access-Control-Allow-Methods  POST  GET  OPTIONS  DELETE  PUT  Header always set Access-Control-Allow-Headers  My-First-Header My-Second-Header Authorization  content-type  csrf-token  Header always set Access-Control-Allow-Credentials  true  x000D   x000D   x000D

User · Answer

If you want just to test a cross domain application in which the browser blocks your request  then you can just open your browser in unsafe mode and test your application without changing your code and without making your code unsafe  From MAC OS you can do this from the terminal line   open -a Google  Chrome --args --disable-web-security --user-data-dir

User · Answer

1  A client downloads javascript code MyCode js from http   siteA - the origin   The code that does the downloading - your html script tag or xhr from javascript or whatever - came from  let s say  http   siteZ   And  when the browser requests MyCode js  it sends an Origin  header saying  Origin  http   siteZ   because it can see that you re requesting to siteA and siteZ    siteA    You cannot stop or interfere with this    2  The response header of MyCode js contains Access-Control-Allow-Origin  http   siteB  which I thought meant that MyCode js was allowed to make cross-origin references to the site B   no   It means  Only siteB is allowed to do this request   So your request for MyCode js from siteZ gets an error instead  and the browser typically gives you nothing   But if you make your server return A-C-A-O  siteZ instead  you ll get MyCode js    Or if it sends      that ll work  that ll let everybody in   Or if the server always sends the string from the Origin  header    but    for security  if you re afraid of hackers  your server should only allow origins on a shortlist  that are allowed to make those requests   Then  MyCode js comes from siteA   When it makes requests to siteB  they are all cross-origin  the browser sends Origin  siteA  and siteB has to take the siteA  recognize it s on the short list of allowed requesters  and send back A-C-A-O  siteA   Only then will the browser let your script get the result of those requests

User · Answer

Who can t control backend for Options 405 Method Not Allowed  Workaround for Chrome browser  execute in command line   C  Program Files  x86  Google Chrome Application chrome exe  --disable-web-security --user-data-dir  path to profile  Example   C  Program Files  x86  Google Chrome Application chrome exe  --disable-web-security --user-data-dir  C  Users vital AppData Local Google Chrome User Data Profile 2

User · Answer

Whenever I start thinking about CORS  my intuition about which site hosts the headers is incorrect  just as you described in your question  For me  it helps to think about the purpose of the same origin policy   The purpose of the same origin policy is to protect you from malicious JavaScript on siteA com accessing private information you ve chosen to share only with siteB com  Without the same origin policy  JavaScript written by the authors of siteA com could make your browser make requests to siteB com  using your authentication cookies for siteB com  In this way  siteA com could steal the secret information you share with siteB com   Sometimes you need to work cross domain  which is where CORS comes in  CORS relaxes the same origin policy for domainB com  using the Access-Control-Allow-Origin header to list other domains  domainA com  that are trusted to run JavaScript that can interact with domainA com   To understand which domain should serve the CORS headers  consider this  You visit malicious com  which contains some JavaScript that tries to make a cross domain request to mybank com  It should be up to mybank com  not malicious com  to decide whether or not it sets CORS headers that relax the same origin policy allowing the JavaScript from malicious com to interact with it  If malicous com could set its own CORS headers allowing its own JavaScript access to mybank com  this would completely nullify the same origin policy     I think the reason for my bad intuition is the point of view I have when developing a site  It s my site  with all my JavaScript  therefore it isn t doing anything malicious and it should be up to me to specify which other sites my JavaScript can interact with  When in fact I should be thinking which other sites JavaScript are trying to interact with my site and should I use CORS to allow them

User · Answer

From my own experience  it s hard to find a simple explanation why CORS is even a concern    Once you understand why it s there  the headers and discussion becomes a lot clearer   I ll give it a shot in a few lines     It s all about cookies  Cookies are stored on a client by their domain        An example story  On your computer  there s a cookie for yourbank com  Maybe your session is in there    Key point  When a client makes a request to the server  it will send the cookies stored under the domain that the client is on       You re logged in on your browser to yourbank com   You request to see all your accounts   yourbank com receives the pile of cookies and sends back its response  your accounts     If another client makes a cross origin request to a server  those cookies are sent along  just as before   Ruh roh      You browse to malicious com  Malicious makes a bunch of requests to different banks  including yourbank com      Since the cookies are validated as expected  the server will authorize the response       Those cookies get gathered up and sent along - and now  malicious com has a response from yourbank    Yikes     So now  a few questions and answers become apparent      Why don t we just block the browser from doing that   Yep  CORS   How do we get around it   Have the server tell the request that CORS is OK

User · Answer

If you are using PHP  try adding the following code at the beginning of the php file   If you are using localhost  try this   header  Access-Control-Allow-Origin         If you are using external domains such as server  try this   header  Access-Control-Allow-Origin  http   www website com

User · Answer

Cross-Origin Resource Sharing - CORS  A K A  Cross-Domain AJAX request  is an issue that most web developers might encounter  according to Same-Origin-Policy  browsers restrict client JavaScript in a security sandbox  usually JS cannot directly communicate with a remote server from a different domain  In the past developers created many tricky ways to achieve Cross-Domain resource request  most commonly using ways are    Use Flash Silverlight or server side as a  proxy  to communicate with remote   JSON With Padding  JSONP    Embeds remote server in an iframe and communicate through fragment or window name  refer here    Those tricky ways have more or less some issues  for example JSONP might result in security hole if developers simply  eval  it  and  3 above  although it works  both domains should build strict contract between each other  it neither flexible nor elegant IMHO    W3C had introduced Cross-Origin Resource Sharing  CORS  as a standard solution to provide a safe  flexible and a recommended standard way to solve this issue    The Mechanism  From a high level we can simply deem CORS is a contract between client AJAX call from domain A and a page hosted on domain B  a typical Cross-Origin request response would be   DomainA AJAX request headers  Host DomainB com User-Agent Mozilla 5 0  Windows NT 6 1  WOW64  rv 2 0  Gecko 20100101 Firefox 4 0 Accept text html application xhtml xml application xml q 0 9     q 0 8 application json Accept-Language en-us  Accept-Encoding gzip  deflate Keep-Alive 115 Origin http   DomainA com    DomainB response headers  Cache-Control private Content-Type application json  charset utf-8 Access-Control-Allow-Origin DomainA com Content-Length 87 Proxy-Connection Keep-Alive Connection Keep-Alive   The blue parts I marked above were the kernal facts   Origin  request header  indicates where the cross-origin request or preflight request originates from   the  Access-Control-Allow-Origin  response header indicates this page allows remote request from DomainA  if the value is   indicate allows remote requests from any domain    As I mentioned above  W3 recommended browser to implement a  preflight request  before submiting the actually Cross-Origin HTTP request  in a nutshell it is an HTTP OPTIONS request   OPTIONS DomainB com foo aspx HTTP 1 1   If foo aspx supports OPTIONS HTTP verb  it might return response like below   HTTP 1 1 200 OK Date  Wed  01 Mar 2011 15 38 19 GMT Access-Control-Allow-Origin  http   DomainA com Access-Control-Allow-Methods  POST  GET  OPTIONS  HEAD Access-Control-Allow-Headers  X-Requested-With Access-Control-Max-Age  1728000 Connection  Keep-Alive Content-Type  application json   Only if the response contains  Access-Control-Allow-Origin  AND its value is     or contain the domain who submitted the CORS request  by satisfying this mandtory condition browser will submit the actual Cross-Domain request  and cache the result in  Preflight-Result-Cache    I blogged about CORS three years ago  AJAX Cross-Origin HTTP request

User · Answer

Simply paste the following code in your web config file   Noted that  you have to paste the following code under  lt system webServer gt  tag       lt httpProtocol gt         lt customHeaders gt          lt add name  Access-Control-Allow-Origin  value       gt          lt add name  Access-Control-Allow-Headers  value  Content-Type    gt          lt add name  Access-Control-Allow-Methods  value  GET  POST  PUT  DELETE  OPTIONS    gt         lt  customHeaders gt       lt  httpProtocol gt

User · Answer

Access-Control-Allow-Origin is a CORS  Cross-Origin Resource Sharing  header   When Site A tries to fetch content from Site B   Site B can send an Access-Control-Allow-Origin response header to tell the browser that the content of this page is accessible to certain origins   An origin is a domain  plus a scheme and port number    By default  Site B s pages are not accessible to any other origin  using the Access-Control-Allow-Origin header opens a door for cross-origin access by specific requesting origins   For each resource page that Site B wants to make accessible to Site A  Site B should serve its pages with the response header   Access-Control-Allow-Origin  http   siteA com   Modern browsers will not block cross-domain requests outright   If Site A requests a page from Site B  the browser will actually fetch the requested page on the network level and check if the response headers list Site A as a permitted requester domain   If Site B has not indicated that Site A is allowed to access this page  the browser will trigger the XMLHttpRequest s error event and  deny the response data to the requesting JavaScript code   Non-simple requests  What happens on the network level can be slightly more complex than explained above  If the request is a  non-simple  request  the browser first sends a data-less  preflight  OPTIONS request  to verify that the server will accept the request  A request is non-simple when either  or both     using an HTTP verb other than GET or POST  e g  PUT  DELETE  using non-simple request headers  the only simple requests headers are    Accept Accept-Language Content-Language Content-Type  this is only simple when its value is application x-www-form-urlencoded  multipart form-data  or text plain     If the server responds to the OPTIONS preflight with appropriate response headers  Access-Control-Allow-Headers for non-simple headers  Access-Control-Allow-Methods for non-simple verbs  that match the non-simple verb and or non-simple headers  then the browser sends the actual request   Supposing that Site A wants to send a PUT request for  somePage  with a non-simple Content-Type value of application json  the browser would first send a preflight request   OPTIONS  somePage HTTP 1 1 Origin  http   siteA com Access-Control-Request-Method  PUT Access-Control-Request-Headers  Content-Type   Note that Access-Control-Request-Method and Access-Control-Request-Headers are added by the browser automatically  you do not need to add them  This OPTIONS preflight gets the successful response headers   Access-Control-Allow-Origin  http   siteA com Access-Control-Allow-Methods  GET  POST  PUT Access-Control-Allow-Headers  Content-Type   When sending the actual request  after preflight is done   the behavior is identical to how a simple request is handled  In other words  a non-simple request whose preflight is successful is treated the same as a simple request  i e   the server must still send Access-Control-Allow-Origin again for the actual response    The browsers sends the actual request   PUT  somePage HTTP 1 1 Origin  http   siteA com Content-Type  application json     myRequestContent    JSON is so great      And the server sends back an Access-Control-Allow-Origin  just as it would for a simple request   Access-Control-Allow-Origin  http   siteA com   See Understanding XMLHttpRequest over CORS for a little more information about non-simple requests

User · Answer

The Access-Control-Allow-Origin response header indicates whether the   response can be shared with requesting code from the given origin    Header type Response       header Forbidden header name      no      A response that tells the browser to allow code from any origin to   access a resource will include the following    Access-Control-Allow-Origin      For more info  visit here

User · Answer

For cross origin sharing  set header   Access-Control-Allow-Origin        Php  header  Access-Control-Allow-Origin         Node  app use  Access-Control-Allow-Origin         This will allow to share content for different domain

[javascript] How does Access-Control-Allow-Origin header work?

WARNING: Not to be used in Production

Examples related to javascript

Examples related to cross-domain

Examples related to cors