CORS (Cross-Origin Resource Sharing) header is supported on all modern browsers. Can I Use cors? Data on support for the cors feature across the major browsers from caniuse.com. 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.
Access-Control-Allow-Origin
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.
Apache
Add the following in httpd.conf or any other in-use configuration file. 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.
Nginx
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.
Access-Control-Allow-Methods
The browser can initiate one or more HTTP methods to access the resources. Ex: – GET, PUT, OPTIONS, PUT, DELETE, POST
Apache
To allow only GET and POST only.
Nginx
Let’s say you need to add DELETE and OPTIONS methods, then you can add as below. After the restart, you should see them in the response headers.
Access-Control-Allow-Headers
The following headers are in safelist means you don’t need to add one. It should work by default.
Content-Type Accept Content-Language Accept-Language
However, if you need to add custom one, you can do it. It supports one or more headers.
Apache
Let’s say you want to allow X-Custom-Header and X-Powered-By headers. After a restart, you should see the result in response headers.
Nginx
An example of adding X-Customer-Software and X-My-Custom header.
Access-Control-Expose-Headers
The following headers are already safe list. Means, you don’t need to add if you want to expose them.
Expires Pragma Cache-Control Last-Modified Content-Language Content-Type
But, if you need other than the safe list, then you can allow them as following.
Apache
Use a wildcard to expose all headers. Note: a wildcard still doesn’t expose Authorization header, and if you need one, you need to mention explicitly. The result should look like this.
Nginx
If you want to expose Origin header.
Access-Control-Max-Age
Do you know the data from Access-Control-Allow-Headers and 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 -1
Apache
To cache for 15 minutes. As you can see, the value is in seconds.
Nginx
To cache for one hour. Once added, restart Nginx to see the results.
Access-Control-Allow-Credentials
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.
Apache
Nginx
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.
Conclusion 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.
