Re: Improving CORS security

Hi James,

Nice post! I've started working with OWASP Secure Headers Project for the
same reason. I saw a lot of websites defining the ACAO dynamically but most
of them were protecting the resources with a CSRF token.
One thing that I noticed when I was researching is that IE11 totally ignore
CORS specification for local files (
different from Chrome and Firefox. Microsoft said this is not a issue.
The problem is that you can trick the user with XSS using a FileAPI ( to save a
html local file, open this file, do any request to any domain and send the
content to a domain you control. Of course the user needs to click on Save,
Open and Allow blocked content buttons but with a good phishing this is not
a big deal.
Another problem that I've noticed some times is about this point mentioned
in the CORS specification (ref.

Because of this, resources for which simple requests have significance
other than retrieval must protect themselves from Cross-Site Request
Forgery (CSRF) by requiring the inclusion of an unguessable token in the
explicitly provided content of the request.

CSRF is possible due a legacy cross-domain operations using POST forms for
example (ref.
Not sure if the CORS simple request is more "open" than these legacy
cross-domain operations but most of the developers/sysadmins don't know
about this problem described on the CORS specification. SameSite ( is a good
solution for CSRF but I didn't check how it's going to work with CORS in
this case.
I was trying to find an improvement for this protection in this case.
Instead of using CSRF tokens let's say that the server can identify that
the request is a CORS simple request so instead of processing the request
and send the CORS headers back it could just send back a not allowed.

Ricardo Iramar

On Tue, May 9, 2017 at 12:41 PM, James Kettle <>

> Hi all,
> After encountering a significant number of websites that have serious
> vulnerabilities due to their use of CORS, I'd like to float a few ideas for
> improvements to the CORS specification and its implementation in browsers.
> Due to limitations in the CORS spec/implementation, numerous websites are
> forced to dynamically generate the access-control-allow-origin header based
> on the incoming Origin header. This creates a situation where websites have
> security-critical functionality based on parsing user input. We could
> reduce the number of sites forced to do dynamic generation by:
> - Enabling static trust of multiple origins by supporting a
> space-separated list of origins
> - Enabling static trust of all subdomains by supporting the use of partial
> wildcards like https://*
> Trusting the 'null' origin is equivalent to trusting * except it's less
> obviously risky, and actually more dangerous since the allow-credentials
> exception for * doesn't apply to null. I think it may be helpful to apply
> the allow-credentials exception to 'null'.
> Websites accessed over HTTPS can use CORS to grant credentialed access to
> HTTP origins, which partially nullifies their use of HTTPS. Perhaps
> browsers' mixed content protection should block such requests, or at least
> disable allow-credentials for HTTP->HTTPS requests.
> I've written a longer blog post on this topic over at
> misconfigurations-for.html and I'll be presenting on this topic at AppSec
> EU on Friday so feel free to say hi if you're around.
> Hopefully this is the right forum to present this ideas, and I'm not five
> years too late.
> Cheers,
> James Kettle

Received on Saturday, 13 May 2017 12:34:01 UTC