What is Cross-Site Request Forgery (CSRF)?

Cross Site Request Forgery (CSRF) is a security vulnerability where attackers trick authenticated users into unknowingly submitting malicious requests to your application. Since these actions are performed within the context of a user’s session, they may lead to unintended changes or data exposure without the user’s consent.

For modern browsers, CSRF attacks can be prevented by using the SameSite cookie attribute. Setting the SameSite cookie attribute to Strict for your session cookie will ensure that the browser won't send the cookie for cross-site requests, eliminating the threat of CSRF. However, if you plan to use looser SameSite settings or support older browsers that don't respect the SameSite attribute, then you'll need to implement your own CSRF protection. One common approach for building CSRF protection is to use the Synchronizer Token pattern.

Implementing the Synchronizer Token Pattern

For implementing CSRF protection in a backend server integration, the Syncrhonizer Token pattern can be used. Here’s an overview of how it looks in the context of a Wristband integration:

1. Authorization Callback & Token Acquisition: After the user successfully authenticates through the Wristband login flow, they are redirected to your backend server’s Callback Endpoint, where the authorization code is exchanged for access and refresh tokens.
2. CSRF Token Generation: While still in the Callback Endpoint, the server generates a CSRF token. The CSRF token should be an encoded (e.g., hex encoded) cryptographically secure random number of at least 16 bytes. The CSRF token is then stored within the application session cookie and a separate CSRF cookie. The CSRF cookie needs to be a non-HTTPOnly cookie so that client-side JavaScript can read the CSRF token inside the cookie.
3. Client-Side JavaScript Sends the CSRF Token in a Custom Header: When client-side JavaScript makes requests to your backend server, it reads the CSRF token from the CSRF cookie and sends it in a custom request header, for example, an X-Csrf-Token header.
4. Server-Side CSRF Middleware Validation: The server's middleware verifies that the CSRF token in the custom request header matches the CSRF token in your application session. If that is not the case, then the server returns an unauthorized error. Note, it's critical that the CSRF middleware uses the CSRF token from the HTTP request header instead of the CSRF token from the CSRF cookie when comparing against the CSRF token in the user's session. The CSRF cookie will still be sent to the server for cross-site requests, so the CSRF token from the CSRF cookie can't be relied on to ensure that the request is coming from the same site. However, only JavaScript running on the same site can read the token from the CSRF cookie and set it in the custom HTTP request header.
5. CSRF Cookie Cleanup on Logout: When the user logs out, the logout endpoint on the server needs to clear the CSRF cookie in addition to the user's session state.