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.