Will "Authorization: Bearer" in request header fix CSRF attacks?

Would this approach actually work to prevent CSRF attacks?

Yes. An attacker can't make a browser send a request that include the authorization header with the correct bearer token. This is for two reasons:

• The attacker can't set the authroization header.
• The attacker don't know the correct value of the token, so they wouldn't know what to set it to.

However, this might be sensitive to changes in your application. For instance, if someone one day decides to change the authentication system to something cookie based, they may not realize that they are disabling your CSRF protection by doing that.

Also, in the case where the required header value is predictable, a CORS policy that allows that header to be set could spell trouble.

As for the linked SO question, I am not sure I understand the accepted answer. But if you look at the second answer, your situation is of type #2 and not type #1.

I know If I am vulnerable to XSS attacks my cookies can be read and the bearer tokens can be stolen. But can the injected XSS create a the Authorization: Bearer header and append the stolen value from cookie?

Yup, you could do that if you can inject code.

If you have an XSS vulnerability, it will allow the attacker to bypass any CSRF protection you put in place. So concerns for XSS can't really be used to favor one form of CSRF protection over another - in the face of XSS they are all void.

A slight difference here is that your token cannot be marked as HTTP-only, since you need to access it from JS to put it in the header. Consequently, an XSS attacker can steal it and then conveniently send requests from her own computer. If the authentication token is HTTP-only the attacker has to make the injected code send the requests, which is a bit of a hassle but not impossible.

It can work, but XSS will compromise the session completely.

The Intent of CSRF mitigations is to limit the scope of who can submit data from a user's browser to the server and cause something to happen. CSRF attacks work by relying on the special properties of web browsers in that they generally include cookies in all requests and the attacker just needs to get the browser to send a request to the target URL. You mitigate this by making the request include data that isn't part of the request normally sent by the browser; e.g. a custom header or form field, injected by JavaScript.

A bearer token in the Authorization header necessarily requires being added by JavaScript because the browser will never include it (barring NTLM/Nego/etc, but that's another topic). So that fits the requirement set out above reasonably well.

The catch is that any JavaScript executed on that page can do the exact same thing as your code adding the header because there are no security boundaries here. That means you're hosed by any form of XSS that allows for arbitrary code execution. And in fact, it puts you in a weaker position because they can just steal your token and do whatever they want with it outside the bounds of a browser, whereas a protected cookie can't be stolen because it's not accessible by JavaScript.

So... you're safe if you can prevent XSS completely, but that's a difficult task under the best circumstances. That said, adding a cookie into the mix doesn't necessarily help because XSS can generate requests that add the token, and the browser will still happily include the cookie.