Cross-Site Request Forgery (CSRF) Protection Methods and Bypasses

Cross-Site Request Forgery is a vulnerability found in web applications that lets a third-party attacker perform sensitive actions on a user's behalf. The exploitation of this bug can target normal users as well as site adminiShare tostrators, sometimes leading to a full compromise of a website. Modern websites tend to deploy some protection mechanisms from this attack. Most of the protection mechanisms are to identify and reject a request that originated from a different website. The protection methods used currently are :

Protection Methods

1. Anti CSRF Token This is a cryptographically strong string that is submitted to the website separately from cookies. This can be sent as a request parameter or as an HTTP header. The server checks for the presence and correctness of this token when a request is made and proceeds only if the token is correct and the cookies are valid.

2. HTTP PUT method The PUT method is used to create instances of a resource on the server. It is similar to POST except that sending the same PUT requests multiple times does not do anything extra. If the server is using the PUT method for sensitive actions, then there is no need for any additional CSRF protection(unless Cross-Origin Resource Sharing is enabled) at that endpoint. It is because the PUT request cannot be duplicated through a web page like a POST request(HTTP forms do not allow PUT requests ). XHR PUT requests, however, can be sent and will be successful if the endpoint has misconfigured CORS.

3. HTTP Bearer Authentication This is a type of HTTP authentication where the user is identified through a token that is submitted in the "Authorization" header of each request. This mechanism solves CSRF because, unlike cookies, it is not submitted by the browser automatically. There are problems and potential bypasses to each of these methods. Anti-CSRF tokens do not have a fixed standard, so their generation mechanism and use depend solely on how developers intended them to be. Due to this lack of a standard, a lot of implementation-specific loopholes exist in web applications.

• Some websites check if the CSRF token is tied to a session or not, but do not verify whether the token is bound to the same session that the request tries to access.
• Some websites send the token in a header/request parameter as well as in a cookie, and these tokens are matched at the server side. If the match is successful, then the operation is allowed. But if the website does not check the authenticity of the token itself and the website is vulnerable to XSS, this mechanism can be easily bypassed by providing a random token in request parameter/header and putting the same token as the cookie by exploiting the XSS vulnerability.
• This can also be bypassed if the endpoint is having a misconfigured CORS.
• If the website is vulnerable to UI redressing(clickjacking), then this mechanism is of no use.

The HTTP PUT method is safe from XSS because there is no "token" to be leaked. But if the website allows Cross-Origin Resource Sharing and it is not properly configured, then an attacker can simply duplicate a PUT request by sending it through XHR. The most common misconfiguration is reflecting the origin header in the response as a value of "Access-Control-Allow-Origin". Along with this, if the PUT method is allowed for CORS requests, then a CSRF attack can be easily done by sending a crafted XHR request to the endpoint. Since the HTMLforms may allow PUT requests in some upcoming standard. SO the developer has to stay updated on it. Also, a misconfigured PUT method can allow arbitrary file upload to the server. The Bearer Authentication is a good way to prevent CSRF, as there is no way for an attacker to know the value of a valid token of an authenticated user. But some websites use both cookies and bearer tokens as an authentication mechanism. In the absence of a token, they may rely on cookies for authentication which will make the web application vulnerable to CSRF. Developers should always keep these things in mind while developing an anti-CSRF mechanism -

1. Never send CSRF tokens over GET requests.
2. Bind the token to a user's session and invalidate it as soon as the session expires.
3. Do not use reversible encoding systems for the creation of CSRF tokens.
4. Do not allow Cross Domain PUT requests if you are relying on PUT requests for CSRF protection.
5. Do not use a single token for each session of a user.

Browser Behavior and Default Protections

Modern browsers include default protections to reduce CSRF risks, mainly through cookie settings and response headers. One key feature is the SameSite cookie attribute, which controls when cookies can be sent. When set to Strict, cookies are only sent during same-site requests; Lax allows them for safe methods like GET; and None sends them always but only over HTTPS. This helps stop unwanted cross-site requests from using your cookies. Another browser-level protection is the X-Frame-Options header, which prevents your website from being loaded inside an iframe — a common method used in clickjacking attacks.

While these features help, developers can’t rely on them alone. Not all browsers enforce them the same way, and outdated browsers may ignore them entirely. Also, if headers like SameSite are missing or misconfigured, the protection won’t work. These tools are useful as extra safety layers, but developers still need to use CSRF tokens, validate requests properly, and keep other security measures like XSS prevention in place.

Conclusion

In conclusion, CSRF is a serious web vulnerability that can let attackers perform unauthorized actions on behalf of users. While modern browsers offer helpful features like SameSite cookies and X-Frame-Options to reduce risk, they are not foolproof. Developers must take extra care by using CSRF tokens correctly, avoiding weak configurations, and not relying solely on browser behavior. Proper server-side validation, secure token handling, and avoiding misconfigured CORS are essential steps to building truly secure web applications.