Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Whether Cross-Site Request Forgery (CSRF) works or not is a combination of intentional security features and accidental legacy protections. CSRF is often known as the "session riding attack". When a website makes a request when you visit the page, cookies are always sent. So, what happens when malicious.com requests amazon.com? This post discusses when and why CSRF exploits work in excellent detail.

Cookies have been and will continue to be used on requests. So, the goal is to prevent attackers from using them via a CSRF attack. A classic mitigation is double submit protection; this places a large random value in the request body and in a cookie. Since the attacker can't read cookies cross-site, this works well. "Cookie tossing" can be done to remove this cookie if the attacker is on the same site though. So, the usage of __Host- can be used here instead.

The SameSite cookie flag can be used to prevent CSRF at a browser level. This has three modes: none, lax and strict. Some browsers default to none because it would break many SSO flows otherwise but others default to lax, breaking many CSRF attacks. Some browsers even default to just two minutes after the cookies were set. This is a very good protection but does have some integration issues.

The Origin header is a surprising safeguard as well. Since this cannot be spoofed, if the backend application knows its domain, it can reject based on the Origin very effectively. This creates some edge cases around the header being removed by Referrer-Policy and by Chrome extensions though.

CORS is not meant to protect against CSRF, but it sort of does! When a "non-simple request" is made, a pre-flight options request is made. Since this is coming from the wrong origin, the browser will reject the request. This is very limiting for CSRF attacks but there are clever work arounds.

Browsers recently introduced Fetch Metadata. On a request, the Set-Fetch-Site header will set it to cross-site, same-site, same-origin or none. Since the browser sets this, it provides excellent CSRF protection by checking this header on the backend. According to some articles, it is now the recommended way to prevent CSRF attacks.

Overall, a fantastic article on the state of CSRF protections in 2025. I'll be referencing this article for years to come!