You will need to have the cookie-parser middleware registered before the doubleCsrfProtection middleware. If you are using express-session then it is also best to register the cookie-parser middleware after that.
This utility will set a cookie containing a hmac based CSRF token, the frontend should include this CSRF token in an appropriate request header or in the body. The getTokenFromRequest option should strictly return the CSRF token from either a request header, or the request body. If you have cases where you need to consider both make these as explicit as possible to avoid the same vulnerability as csurf, do not just use fallthroughs (||, ??).
If you are using TypeScript, requires TypeScript >= 3.8
@@ -78,14 +78,14 @@ const { validateRequest, // Also a convenience if you plan on making your own middleware. doubleCsrfProtection, // This is the default CSRF protection middleware. } = doubleCsrf({ - getSecret = (req) => 'return some cryptographically pseudorandom secret here', - getSessionIdentifier = (req) => req.session.id // return the requests unique identifier + getSecret: (req) => 'return some cryptographically pseudorandom secret here', + getSessionIdentifier: (req) => req.session.id // return the requests unique identifier }); ```
This will extract the default utilities, you can configure these and re-export them from your own module. Primarily csrf-csrf was built to support Single Page Applications (SPAs), or frontends hosted cross-site to their backend, the default configuration is optimised for this usecase. If you are changing any of the configuration you should ensure you understand the impact of the change. Consult the documentation for the respective configuration option and also consider reading the FAQ.
-
To create a route which generates a CSRF token and a cookie containing the CSRF token: @@ -173,10 +173,10 @@ const doubleCsrfUtilities = doubleCsrf({ getSessionIdentifier: (req) => req.session.id, // A function that returns the unique identifier for the request cookieName: "__Host-psifi.x-csrf-token", // The name of the cookie to be used, recommend using Host prefix. cookieOptions: { - sameSite = "strict", - path = "/", - secure = true, - httpOnly = true, + sameSite: "strict", + path: "/", + secure: true, + httpOnly: true, ...remainingCookieOptions // See cookieOptions below }, size: 32, // The size of the random value used to construct the message used for hmac generation @@ -437,7 +437,7 @@ req.csrfToken(req, res, { overwrite: false });
The generateCsrfToken function serves the purpose of establishing a CSRF protection mechanism by generating a token and an associated cookie. This function also provides the option to utilise a third parameter, which is an object that may contain: overwrite, and cookieOptions. By default, overwrite is set to false. cookieOptions if not provided will just default to the options originally provided to the initialisation configuration, any options that are provided will override those initially provided.
It returns a CSRF token and attaches a cookie to the response object. The cookie content is `${hmac}${csrfTokenDelimiter}${randomValue}`.
In some cases you should only transmit your token to the frontend as part of a response payload. Consult the "Do I need csrf-csrf?" and "Does httpOnly have to be true?" sections of the FAQ.
+In some cases you should only transmit your token to the frontend as part of a response payload. Consult the "Do I need csrf-csrf?" and "Does httpOnly have to be true?" sections of the FAQ.
When overwrite is set to false, the function behaves in a way that preserves the existing CSRF token. In other words, if a valid CSRF token is already present in the incoming request cookie, the function will reuse the existing CSRF token.
If overwrite is set to true, the function will generate a new token and cookie each time it is invoked. This behavior can potentially lead to certain complications, particularly when multiple tabs are being used to interact with your web application. In such scenarios, the creation of new cookies with every call to the function can disrupt the proper functioning of your web app across different tabs, as the changes might not be synchronised effectively (you would need to write your own synchronisation logic).
If overwrite is set to false, the function will return the existing CSRF token from the existing CSRF token cookie.