javascript - XMLHttpRequest cannot load https://www.[website].com/ -


i have grunt process initiates instance of express.js server. working absolutely fine until when started serving blank page following appearing in error log in developer's console in chrome (latest version):

xmlhttprequest cannot load https://www.[website].com/ no 'access-control-allow-origin' header present on requested resource. origin 'http://localhost:4300' therefore not allowed access.

what stopping me accessing page?

about same origin policy

this same origin policy. security feature implemented browsers.

your particular case showing how implemented xmlhttprequest (and you'll identical results if use fetch), applies other things (such images loaded onto <canvas> or documents loaded <iframe>), different implementations.

the standard scenario demonstrates need sop can demonstrated three characters:

  • alice person web browser
  • bob runs website (https://www.[website].com/ in example)
  • mallory runs website (http://localhost:4300 in example)

alice logged bob's site , has confidential data there. perhaps company intranet (accessible browsers on lan), or online banking (accessible cookie after entering username , password).

alice visits mallory's website has javascript causes alice's browser make http request bob's website (from ip address cookies, etc). simple using xmlhttprequest , reading responsetext.

the browser's same origin policy prevents javascript reading data returned bob's website (which bob , alice don't want mallory access). (note can, example, display image using <img> element across origins because content of image not exposed javascript … unless throw canvas mix in case will generate same origin violation error).


why same origin policy applies when don't think should

for given url possible sop not needed. couple of common scenarios case are:

  • alice, bob , mallory same person.
  • bob providing entirely public information

… browser has no way of knowing if either of above true, trust not automatic , sop applied. permission has granted explicitly before browser give data given different website.


why same origin policy applies javascript in web page

browser extensions, network tab in browser developer tools , applications postman installed software. aren't passing data 1 website javascript belonging different website just because visited different website. installing software takes more conscious choice.

there isn't third party (mallory) considered risk.


why can display data in page without reading js

there number of circumstances mallory's site can cause browser fetch data third party , display (e.g. adding <img> element display image). isn't possible mallory's javascript read data in resource though, alice's browser , bob's server can that, still secure.


cors

the access-control-allow-origin header referred in error message part of cors standard allows bob explicitly grant permission mallory's site access data via alice's browser.

a basic implementation include:

access-control-allow-origin: * 

… permit website read data.

access-control-allow-origin: http://example.com/ 

… allow specific site access it, , can dynamically generate based on origin request header permit multiple, not all, sites access it.

the specifics of how set response header depend on bob's http server and/or server side programming language. there a collection of guides various common configurations might help.

nb: requests complex , send preflight options request server have respond before browser send get/post/put/whatever request js wants make. implementations of cors add access-control-allow-origin specific urls tripped this.


obviously granting permission via cors bob only if either:

  • the data not private or
  • mallory trusted

if bob in scenario, specifics of how add cors permission headers depend on combination of choice of http server software , language using server side programming (if any).

mallory can't add header because has permission bob's site , silly (to point of rendering sop useless) able grant herself permission.


error messages mention "response preflight"

some cross origin requests preflighted.

this happens when (roughly speaking) try make cross origin request that:

  • includes credentials cookies
  • couldn't generated regular html form (e.g. has custom headers or content-type couldn't use in form's enctype).

in these cases the rest of answer still applies need make sure server can listen preflight request (which options (and not get, post or whatever trying send) , respond right access-control-allow-origin header access-control-allow-methods , access-control-allow-headers allow specific http methods or headers.


alternatives cors

jsonp

bob provide data using hack jsonp how people did cross-origin ajax before cors came along.

it works presenting data in form of javascript program injects data mallory's page.

it requires mallory trust bob not provide malicious code.

note common theme: site providing data has tell browser ok third party site access data sending browser.

move 2 resources single origin

if html document js runs in , url being requested on same origin (sharing same scheme, hostname, , port) same origin policy grants permission default. cors not needed.

a proxy

mallory could use server side code fetch data (which pass server alice's browser through http usual).

it either:

  • add cors headers
  • convert response jsonp
  • exist on same origin html document

that server side code hosted third party (such yql).

bob wouldn't need grant permissions happen.

this fine since between mallory , bob. there no way bob think mallory alice , provide mallory data should kept confidential between alice , bob.

consequently, mallory can use technique read public data.

writing other webapp

as noted in section "why same origin policy applies javascript in web page", can avoid sop not writing javascript in webpage.

that doesn't mean can't continue use javascript , html, distribute using other mechanism, such node-webkit or phonegap.


other security risks

note sop / cors not mitigate xss, csrf, or sql injection attacks need handled independently.


summary

  • there nothing can in your client-side code enable cors access else's server.
  • if control server request being made to: add cors permissions it.
  • if friendly person controls it: them add cors permissions it.
  • if public service: read api documentation see accessing client side javascript. might tell use specific urls or use jsonp (or might not support @ all).
  • if none of above apply: browser talk your server instead, , have server fetch data other server , pass on.

Comments

Popular posts from this blog

python Tkinter Capturing keyboard events save as one single string -

android - InAppBilling registering BroadcastReceiver in AndroidManifest -

javascript - Z-index in d3.js -