Cross-Site Request Forgery (CSRF) Complete Guide with Examples

I am a relatively new Bug Bounty Hunter and do not claim to be a professional! Just trying to share my experience from the perspective of a newbie. I expect all readers to have basic understanding of CSRF.

Illustration by


  • Introduction (Above)
  • Attack Vector — Where to Look
  • Confirming CSRF
  • Tips and Tricks

Attack Vector

Confirming CSRF

  • Leave CSRF Token empty
  • Use other account’s CSRF Token
  • Delete header or request body CSRF Token entirely
CSRF Token can come in different names. Be on the lookout!

If the above method is successfully, proceed to the next phase!

A lot of companies integrate multi-layer protection. On top of implementing CSRF Token, only whitelisted domains are allowed for both Origin and Referer header, therefore both headers play an equal part in blocking CSRF attack by only allowing whitelisted domains. Therefore, the next step is to alter both Origin and Referer headers. A good rule of thumb is to do the following:

*Since most companies focus mainly on the Origin Header, test the above to the Origin Header first then proceed to the Referer Header.

Being able to change the Content-Type is also crucial in exploiting CSRF vulnerability. The main Content-Type used in CSRF vulnerabilities are ‘text/plain’ and ‘application/x-www-form-urlencoded’. Make sure to tamper with the Content-Type Header and confirm that the server is still accepting the above content type. Being able to alter Content-Type will allow us to create an easier PoC!

PoC Example using ‘application/x-www-form-urlencoded’

Another thing to keep in mind is Cookie ‘Same-Site’ Attribute. If our target company implements ‘Same-Site: Lax’ for their cookies, then it will be impossible for us to exploit CSRF. Although this is the case, most companies probably leave their Cookie ‘Same-Site’ attribute to default, which starting from Chrome 84, will be treated as ‘Same-Site: Lax’. This can still be bypassed using the 2 minutes rule. If a Cookie ‘Same-Site’ attribute is set to default, there is a 2 minutes window where all of the cookies will be included from a third-party when new cookies are set by the server. Therefore, what we need to do is to chain logout/login CSRF with our current CSRF. Nonetheless, if the above requirement has been satisfied, I recommend testing the ‘plain’ CSRF first. If the CSRF does not fully send your cookie, then resort to chaining logout/login CSRF.

Same-Site Attribute for Cookies