Restrict or allow resource sharing between sites using CORS header.
CORS (Cross-Origin Resource Sharing) header is supported on all modern browsers.
By default, the browser restricts cross-origin HTTP requests through scripts. And, CORS can be handy to reuse the common application resources on other web applications. Once it is added correctly, it instructs the browser to load the application from a different origin.
There are six popular types of CORS headers a server can send. Let’s explore them.
The most popular one that it tells the browser to load the resources on the allowed origin. It supports wildcard (*) and doing so any domain can load the resources. However, it does have an option to allow a specific origin.
Add the following in
httpd.conf or any other in-use configuration file.
Header set Access-Control-Allow-Origin "*"
Restart the Apache to test. You should see them in response headers.
And, to allow from a specific origin (ex: https://gf.dev), you can use the following.
Header set Access-Control-Allow-Origin "https://gf.dev"
Here is an example to allow origin https://geekflare.dev. Add the following in the
server block of
nginx.conf or in-use configuration file.
add_header Access-Control-Allow-Origin "https://geekflare.dev";
The browser can initiate one or more HTTP methods to access the resources. Ex: – GET, PUT, OPTIONS, PUT, DELETE, POST
To allow only GET and POST only.
Header add Access-Control-Allow-Methods "GET, POST"
Let’s say you need to add DELETE and OPTIONS methods, then you can add as below.
add_header Access-Control-Allow-Methods "DELETE, OPTIONS";
After the restart, you should see them in the response headers.
The following headers are in safelist means you don’t need to add one. It should work by default.
However, if you need to add custom one, you can do it. It supports one or more headers.
Let’s say you want to allow
Header always set Access-Control-Allow-Headers "X-Custom-Header, X-Powered-By"
After a restart, you should see the result in response headers.
An example of adding X-Customer-Software and X-My-Custom header.
add_header Access-Control-Allow-Headers "X-Custom-Software, X-My-Custom";
The following headers are already safe list. Means, you don’t need to add if you want to expose them.
But, if you need other than the safe list, then you can allow them as following.
Use a wildcard to expose all headers.
Header always set Access-Control-Expose-Headers "*"
Note: a wildcard still doesn’t expose
Authorization header, and if you need one, you need to mention explicitly.
Header always set Access-Control-Expose-Headers "Authorization, *"
The result should look like this.
If you want to expose
add_header Access-Control-Expose-Headers "Origin";
Do you know the data from
Access-Control-Allow-Methods headers can be cached? It can be cached for up to 24 hours in Firefox, 2 hours in Chrome (76+).
To disable the caching, you can keep the value as
To cache for 15 minutes.
Header always set Access-Control-Max-Age "900"
As you can see, the value is in seconds.
To cache for one hour.
add_header Access-Control-Max-Age "3600";
Once added, restart Nginx to see the results.
There is only one option to set here – true.
This is to allow if you want to expose credentials such as cookies, TLS certificates, authorization.
Header always set Access-Control-Allow-Credentials "true"
add_header Access-Control-Allow-Credentials "true";
and the result.
Verifying the results
Once the necessary headers are added, you can either use browser in-built developer tools or an online HTTP header checker.
I hope the above helps you to implement the CORS header in Apache HTTP and the Nginx web server for better security. You may also be interested in applying OWASP recommended secure headers.