[ad_1]
HTML5 cross-origin resource sharing (CORS) is a browser mechanism that enables controlled access to resources located outside of a given domain. CORS is a powerful technology, which is easy to configure wrong – and high severity exploits are often relatively easy for an attacker to find.
CORS checks performed by Dastardly
CORS enabled
It’s easy to unintentionally enable CORS when building a web application. Some libraries turn CORS on by default, for instance. Or you might wish to have CORS enabled for an API, but accidentally enable it for your whole application.
Dastardly dynamically checks whether CORS is enabled in your application – and notifies you if it is. This serves as a reminder to check your CORS implementation, and to remove any unnecessary domains (e.g. test domains) from your CORS policy before deployment.
CORS: arbitrary origin trusted
If an application is set to trust arbitrary domains (as opposed to using an allow list / “whitelist”), then this effectively disables CORS – granting two-way interaction to any website that requests it. Unless the application’s response contains solely unprotected public content, such a policy is likely to constitute a security risk. Despite this, during development, applications are sometimes set to trust arbitrary origins – often for purposes of convenience.
It’s imperative to check that an application’s CORS implementation is only set to trust arbitrary origins when this is truly necessary. If your application uses CORS, Dastardly dynamically checks to see if it trusts arbitrary domains, and will warn you in your CI/CD pipeline if this configuration is detected.
CORS: all subdomains trusted
If an application’s CORS policy is set to allow two-way interaction with all subdomains, then this can significantly increase that application’s susceptibility to…
..
[ad_2]
