Cross-origin resource sharing can be considered as one of the attacks that the website application server vulnerabilities. Normally, it will enable any controlled access to the bug located where it will run the Cross-origin rules such as Access-Cross-Allow-Origin:
However, this will affect if CORS is been misconfigured and wrong implemented on the website application or server will alert the attacker of the potential of the website vulnerabilities.
Nowadays, CORS will only allow the credential request as long as the request is been permitted by the browser. However, the Samesite request will not be sent even though CORS has to allow the third domain to access.
Vulnerabilities that will be arising from CORS will be Access-Cross-Allow-Origin where will be generated by a client-specified header. This vulnerability can be verified by reading the Origin header whenever you access a vulnerabilities website.
An example of the request will be included Origin: <URL address> while an example of the response will have Access-Cross-Allow-Origin:<URL address>
Once the attacker notices that the website is responding with Acces-Cross-Allow-Origin, they can use any domain to access the vulnerability domain. If the response contains any privacy details or any sensitive such as API KEY(X-API-KEY: abc12345! )
A system administrator can set whitelist to the Origin where the value would be null on the header. An example of the situation where the browser will send the value null as follows:
- Redirection of the Cross-Site
- Serialized data request
- Cross-Origin requests from the Sandboxed
- File protocol is been used from the request
The Recommendation for the CORS attack would be that the System Administrator would need to properly configure the Allow-Origin Header and try to avoid using null on the Origin Header. Besides that, the user will need to surf the trusted website comparing to the website Cross-Origin without validation should be avoided at any cost