You may be unaware that the web pages that you use will often initiate requests to load fonts, images and other assets from several different places on the Internet. It is important that checks verify these requests so that your browser security remains uncompromised.
If there are no checks made, you could experience browser hijacking or your browser forced to download malware or some other malicious code. Modern browsers have security policies that mitigate this risk.
Browser Security Policies
You probably know that web servers host pages of a website, images, applications, fonts and a lot more. When you use a browser, you will access webpages hosted on different web servers. Many websites request resources for their pages from other servers located elsewhere on the Internet.
A very restrictive browser security policy is “same origin”. What this means is that the browser will only accept requests for assets that are stored on the same server as the webpages. An origin consists of:
- The host
- Protocol
- Port number
In order for a same origin browser policy to work, all parts of the origin have to match. If this is not the case then the browser refuses the request from the user. To overcome the restrictiveness of a same origin security policy, there are “cross origin” policies that are a lot more flexible.
A cross origin security policy is like a mixture of no security policy and a same origin security policy. Cross origin has developed over the years and now there is a standard for cross origin resource sharing (CORS).
What is Cross Origin Resource Sharing (CORS)?
So many websites make requests for assets from other web servers that CORS is a very necessary standard. If there was only “same origin” policies available then webpages could only display assets stored on the same web server. This would mean that any images used on a page would have to be stored on the same web server for example.
To make cross origin requests safe, servers have to implement a method of handling requests for assets on other servers. With CORS, servers can specify which origins can access server assets and other things as well.
Using the CORS standard enables servers to specify who can legitimately access its assets and the method required to access them. A cross origin request uses http requests such as GET. Most servers will comply with an http GET request. However, a server is likely to reject http requests like DELETE, PUT and PATCH as this could result in malicious acts.
How CORS manages Cross Origin requests
So with CORS, servers can specify the http requests permissible from external webpages. CORS is able to effectively manage cross origin requests with the addition of new http headers to the standard header list. These are those new http headers all starting with Access-Control:
- Allow-Origin
- Allow-Credentials
- Allow-Headers
- Allow-Methods
- Expose-Headers
- Max-Age
- Options
- Request-Headers
- Request-Method
All of these new headers are important, but probably the most important is Allow-Origin as this enables servers to specify exactly how to share their assets with external websites. So for example, if a server receives a GET request it responds with a value for the CORS Allow-Origin header.
In the majority of cases the server will return the value “*” which means that any domain can access their assets. If this is not desirable, the server could set the value to a single domain or a domain list.
It is highly likely that a server will deny any requests to modify any assets that it has stored. A server will not just blindly deny such a request, it will initiate a process that will first check if such a request is permitted and then communicate to the browser which type of requests it permits.
Requests to modify assets are “preflight” and use the CORS “options” header. Any preflight request gets sent prior to original requests. The reason for this is that a preflight request determines if the original request is safe or not.
Therefore, if a server identifies a safe original request it will allow it. If the original request is DELETE for example, then the preflight response will deny the original request. Modified browser headers are also likely to trigger preflight requests.
How to enable CORS
Enabling the request headers for the CORS standard depends on the framework and language of the backend. Please read this excellent resource on how to enable CORS with your web hosting account.
If you have a premium web hosting account with us, we will be delighted to help you with the enabling of CORS. You need to check out our premium web hosting packages if you do not currently host your websites with us.
We offer the latest cutting-edge server hosting that provides page loads at lightning speeds. The security of your websites is a prime concern for us and all of our packages include Imunify360 to keep your websites safe from malware.
You can benefit from many other features with our affordable premium web hosting. Please check out our high quality hosting packages.
