This is a very similar method to using the X-Requested-With
header, just that X-Header
is used instead (neither of which are standard headers, although X-Requested-With
could be considered a de-facto standard).
This is a valid method of preventing CSRF as only the following headers are allowed cross domain:
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type
any others cause a "pre-flight" request to be issued in CORS supported browsers. Non CORS browsers will ignore other headers.
As long as the CORS configuration isn't allowing the header and domain the attacker is using then this is a valid method.
If CORS was enabled and was allowing the attacker's domain, then other methods of CSRF protection such as the recommended Synchronizer Token Pattern would also fail because the attacker could make a GET request to retreive the token value (assuming the access-control-allow-credentials
header is set to true). Note that lack of CORS does not prevent requests from being made by the browser, it only prevents the responses from being read.
So, it appears that you're out of luck for a CSRF exploit, unless another Flash or browser plugin bug/feature will allow you to add the header to the request.