csrf-csrf - npm Package Versions

4.0.3 (2025-05-27)

generateCsrfToken will now always check if the existing token is valid before returning it. This validation is only derived from the request cookie, this way GET requests are not expected to include the CSRF token to ensure token reuse, this was a bug and not the intended/expected behavior.

If the CSRF token container in the request is somehow invalid when generateCsrfToken is called, this will be silently ignored and a new valid CSRF token will be generated and returned. If validateOnReuse is set to true, an error will be thrown instead.

Bug Fixes

• validateOnReuse incorrectly throws (26b3dd6)

4.0.2 (2025-05-09)

Bug Fixes

• broken type exports (8967de6)

4.0.1 (2025-05-08)

Bug Fixes

• correctly skip CSRF token validation when validateOnReuse is false (bcaf1c3)

4.0.0 (2025-04-27)

⚠ BREAKING CHANGES

This list may not be an exhaustive list of breaking changes, for more information consult the version 3 -> 4 upgrade guide and the updated configuration documentation in the README.

• Token generation now uses createHmac, the format has changed significantly, see the CSRF token format section of the upgrade guide.
• getSessionIdentifier is now required and must return a unique identifier per-request (and per-session) - this is an essential part of CSRF token security
• getTokenFromRequest renamed to getCsrfTokenFromRequest
• generateToken renamed to generateCsrfToken
• overwrite and validateOnReuse parameters for generateCsrfToken have been merged into a single object parameter which also accepts cookieOptions: generateCsrfToken(req, res, options);
• Default value for validateOnReuse is now false
• Default value for cookieOptions.sameSite is now strict
• cookieOptions.signed is no longer available, CSRF tokens are inherently signed, this is redundant
• delimiter option removed, csrfTokenDelimiter and messageDelimiter are now used for the respective purpose
• signed option in cookieOptions config option removed (redundant), csrf tokens generated by csrf-csrf are inherently signed
• size config option now sets the size of the message used to construct the hmac, now defaults to 32 instead of 64, this is combined with the return value of getSessionIdentifier to construct the hmac payload
• Type CsrfTokenCookieOverrides renamed to CsrfTokenCookieOptions
• Type CsrfTokenCreator renamed to CsrfTokenGenerator
• Type doubleCsrfProtection renamed to DoubleCsrfProtection
• Type RequestMethod renamed to CsrfRequestMethod
• Type CsrfIgnoredMethods renamed to CsrfIgnoredRequestMethods

Features

• change default value of sameSite to 'strict' (ba5973e)
• change validateOnReuse to false by default (5fc62a9)
• expose per token cookie settings (#60) (456b317)
• types: add CsrfTokenGeneratorRequestUtil type (72fd659)
• use hmac to generate csrf tokens (e4c5ec3)

3.2.2 (2025-04-24)

Bug Fixes

• types: fix incorrect type for Request#csrfToken (cf3dfe2), closes #95

3.2.1 (2025-04-20)

No changes, just re-published the botched 3.2.0

3.2.0 (2025-04-20)

Features

• add optional skipCsrfProtection callback config option (d3f8123)

3.1.0 (2024-11-25)

Features

• re-allow httpOnly override (e6f2543)
• support custom delimiter for cookie value separation (59d84a1)

3.0.8 (2024-09-23)

• No changes, release issue on 3.0.7

3.0.7 (2024-09-21)

• Marked >= 3.0.7 as security supported version

Features

• support optional stateless association of token with session (710d2f6)

Added the getSessionIdentifier parameter to the csrf-csrf configuration. By providing the getSessionIdentifier callback, generated tokens will only be valid for the original session identifier they were generated for.

For example: (req) => req.session.id

The token will now be signed with the session id included, this means a generated CSRF token will only be valid for the session it was generated for. This also means that if you rotate your sessions (which you should) you will also need to generate a new CSRF token for the session after rotating it.