Is it true that custom HTTP headers can be used to prevent CSRF because the browser prevents sites f-CodePudding

I was studying CSRF today and I found the following sentence:

custom HTTP headers can be used to prevent CSRF because the browser prevents sites from sending custom HTTP headers to another site but allows sites to send custom HTTP headers to themselves

Inside this article: https://www.invicti.com/web-vulnerability-scanner/vulnerabilities/cross-site-request-forgery-in-login-form-invicti/

Can someone explain this concept better to me and tell me if the sentence is correct?

Can I assume that if I send a CSRF token inside a custom HTTP header the attacker can't do it?

CodePudding user response：

Can someone explain this concept better to me and tell me if the sentence is correct?

The sentence is correct in so far as modern browsers that implement the CORS protocol will refuse to make requests that are initiated by a foreign ("cross-origin") web page and that go beyond what a simple click on a hyperlink or submission of an HTML form could achieve. For example, they refuse such requests if they contain the X-Requested-With: XMLHttpRequest header. Also, such cross-origin requests are still made if the target of the request declares the foreign web page trustworthy (through an Access-Control-Allow-* header in a preflight response).

But CSRF tokens are still needed for "simple" requests, such as ones initiated by submitting an HTML form. These requests cannot contain non-standard headers and must therefore transfer the CSRF token in a (hidden) form field.

Can I assume that if I send a CSRF token inside a custom HTTP header the attacker can't do it?

See this explanation.