Frontend Security Best Practices for CSRF Protection

To prevent CSRF attacks, the front-end requires cooperation with the back-end. The front-end can enhance protection by: 1. Set the SameSite Cookie attribute to Lax or Strict to limit the automatic sending of cookies in cross-site requests; 2. Avoid sensitive operations using GET requests, and use non-idempotent methods such as POST to prevent induce triggering; 3. When the page is loaded, the Anti-CSRF Token generated by the back-end is obtained and carried in the request header; 4. Use the dual submission cookie mode, the back-end writes the token to the HttpOnly cookie, and puts it in the request header after the front-end reads it, and the back-end verifies consistency. The above measures should be used in combination to improve overall safety.

Preventing CSRF (cross-site request forgery) attacks is a part of front-end security that cannot be ignored. Although the backend plays a core role in defending against such attacks, the frontend can also enhance its protection capabilities through some means. Here are a few practical front-end security practices that can effectively help you reduce CSRF risks.

Use SameSite Cookie Attribute

CSRF attacks usually rely on credentials automatically sent by the user's browser, such as session cookies. Setting SameSite property can limit the sending behavior of cookies in cross-site requests.

• SameSite=Strict : The cookie is not sent in any cross-site request, which is highly secure, but may affect the user experience.
• SameSite=Lax : Allows some secure cross-site requests (such as navigating to the target website), taking into account both security and experience.
• SameSite=None : Must be used with Secure property, suitable for scenarios where cookies are required to be carried across domains, such as embedded iframes.

It is recommended to set authentication-related cookies to SameSite=Lax or Strict as much as possible to reduce the CSRF attack surface.

Avoid designing sensitive operations as GET requests

GET requests are easily triggered, such as clicking through <img src="/static/imghw/default1.png" data-src="https://img.php.cn/upload/article/000/000/000/175286847314881.jpg" class="lazy" alt="Frontend Security Best Practices for CSRF Protection" > , <script></script> or links. However, POST, PUT, DELETE and other methods are relatively difficult to forge.

If you have an account deletion operation that is implemented through GET /api/delete-account , then the attacker only needs to induce the user to access an image link:

 <img  src="/static/imghw/default1.png"  data-src="https://your-site.com/api/delete-account"  class="lazy" / alt="Frontend Security Best Practices for CSRF Protection" >

You can complete a malicious request. Therefore, all operations involving state changes should be implemented using non-idempotent methods such as POST and avoid exposure to simple URLs.

Add Anti-CSRF Token (combined with backend)

Although the front-end itself cannot generate and verify anti-CSRF tokens separately, it can be fetched from the server when the page is loaded and actively bring it with you in each request.

Common practices include:

• Store the token in a hidden input element or in a JS variable.
• Add this token in the AJAX request header, such as XSRF-TOKEN .
• If you use a framework such as React Axios, you can use an interceptor to handle it uniformly.

Note: The token must be generated, verified by the backend, and cannot be stored in localStorage in case of XSS leak.

Use dual submission cookie mode (suitable for front-end and back-end separation architecture)

This is a solution commonly used in SPA applications, and the process is as follows:

1. After the login is successful, the backend writes the CSRF token to an HttpOnly cookie.
2. The front-end reads the cookie and places it in the request header (such as X-CSRF-Token ).
3. The backend simultaneously verifies whether the cookie and the token in the request header are consistent.

The advantage of this method is that it does not require the server to maintain the state of the token, and it can also prevent cross-domain requests.

Note: This method requires that both the front and back ends support CORS and are configured correctly, otherwise the token will not be able to read or send correctly due to cross-domain issues.

The above methods are not used in isolation, but should be combined and applied according to the actual situation of the project. Although Frontend can do CSRF defense, it can significantly improve overall security based on the backend. Basically all this is not complicated but easy to ignore.

The above is the detailed content of Frontend Security Best Practices for CSRF Protection. For more information, please follow other related articles on the PHP Chinese website!