Stands for "Cross-Origin Resource Sharing." CORS allows scripts on webpages to request resources from other domains. Most web browsers block these types of requests by default for security purposes.
A webpage can request resources from another domain — as long as the requests come from the HTML. For example, the <head> section may reference resources, such as CSS files, fonts, and JS files other domains. Examples include Google Analytics scripts, jQuery libraries, and fonts hosted on another server. Similarly, the <body> can request images from a CDN or other domain. Cross-origin resource requests in the HTML do not require CORS permissions.
When a script or iframe element makes a cross-origin request, CORS is required. For example, an AJAX method – which runs after the page is loaded – cannot request a resource from another domain. CORS overrides this default browser setting and allows the request to go through.
CORS is implemented using "access control" HTTP headers. A server admin can add or modify the response headers, which are sent to a client's browser when a webpage is accessed. These settings, which can be applied to Apache and IIS servers, may be site-specific or server-wide. Below are common request and response headers:
CORS Request Headers:
CORS Response Headers:
If a script on techterms.com requests a resource from sharpened.com using a GET action, it may send the following request headers:
Origin: https://techterms.com Access-Control-Request-Method: GET
To allow the request, sharpened.com may respond with the following headers:
Access-Control-Allow-Origin: https://techterms.com Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin can be set to specific domains or a wildcard using an asterisk (*). The wildcard setting allows cross-resource requests from all domains, which may be a security risk. Access-Control-Allow-Methods can be set to PUT, POST, DELETE, and others, including a wildcard (*) setting that allows all methods.