CSRF
Related Docs:
object CSRF
| package middleware
Check for CSRF validity for an unsafe action.
Check for CSRF validity for an unsafe action.
Check for CSRF validity for an unsafe action.
Exposed to users in case of manual plumbing of csrf token (i.e websocket or query param)
Create a Response cookie from a signed CSRF token
Create a Response cookie from a signed CSRF token
the signed csrf token
Embed a token into a response *
Decode our CSRF token, check the signature and extract the original token string to sign
Generate a new token *
Extract a CsrfToken, if present, from the request,
then try generate a new token signature, or fail with a validation error.
Extract a CsrfToken, if present, from the request,
then try generate a new token signature, or fail with a validation error.
If not present, generate a new token
newly refreshed token
Extract a CsrfToken, if present, from the request,
then try to generate a new token signature, or fail with a validation error
Extract a CsrfToken, if present, from the request,
then try to generate a new token signature, or fail with a validation error
newly refreshed token
Sign our token using the current time in milliseconds as a nonce Signing and generating a token is potentially a unsafe operation if constructed with a bad key.
Constructs a middleware that will check for the csrf token presence on both the proper cookie, and header values, if the predicate is not satisfied
Constructs a middleware that will check for the csrf token presence on both the proper cookie, and header values, if the predicate is not satisfied
If it is a valid token, it will then embed a new one, to effectively randomize the complete token while avoiding the generation of a new secure random Id, to guard against [BREACH](http://breachattack.com/)
Middleware to avoid Cross-site request forgery attacks. More info on CSRF at: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
This middleware is modeled after the double submit cookie pattern: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie
When a user authenticates,
embedNewis used to send a random CSRF value as a cookie. (Alternatively, an authenticating service can be wrapped inwithNewToken).By default, for requests that are unsafe (PUT, POST, DELETE, PATCH), services protected by the
validatedmethod in the middleware will check that the csrf token is present in both the headerheaderNameand the cookiecookieName. Due to the Same-Origin policy, an attacker will be unable to reproduce this value in a custom header, resulting in a403 Forbiddenresponse.By default, requests with safe methods (such as GET, OPTIONS, HEAD) will have a new token embedded in them if there isn't one, or will receive a refreshed token based off of the previous token to mitigate the BREACH vulnerability. If a request contains an invalid token, regardless of whether it is a safe method, this middleware will fail it with
403 Forbidden. In this situation, your user(s) should clear their cookies for your page, to receive a new token.The default can be overridden by modifying the
predicateinvalidate. It will, by default, check if the method is safe. Thus, you can provide some whitelisting capability for certain kinds of requests.We'd like to emphasize that you please follow proper design principles in creating endpoints, as to not mutate in what should otherwise be idempotent methods (i.e no dropping your DB in a GET method, or altering user data). Please do not use the CSRF protection from this middleware as a safety net for bad design.