Now, every non-safe request will be validated against CSRF attacks.
Note
If you add this middleware to the root route, it will apply to every route in your application. If your app has API routes that should accept cross-site requests (e.g., for webhooks or third-party integrations), you should move the CSRF middleware to a layout route that wraps only your UI routes, leaving API routes unprotected by CSRF validation.
The middleware uses the Sec-Fetch-Site header to determine request origin. Requests from same-origin or same-site are automatically allowed. For cross-site requests, you can specify trusted origins to allow.
The request origin is determined by checking (in order):
The Origin header
The Referer header
The request.referrer property
Allowing Cross-Site Requests
You can allow cross-site requests from specific origins using a string:
Enabling allowMissingOrigin is high risk. When enabled, requests without a parseable origin (missing Origin/Referer headers, Sec-Fetch-Site header, or Origin: null) will bypass origin validation entirely. This can allow attackers to perform cross-site requests in environments that don't send origin headers. Only use this option when you're certain that clients without origin headers are within your trusted boundary, or pair it with an additional CSRF token mechanism.
Custom Untrusted Request Handler
You can provide a custom handler for requests that fail CSRF validation:
Install using
bunx shadcn@latest add @remix-utils/middleware-csrf.The CSRF middleware protects your application from Cross-Site Request Forgery attacks by validating that requests originate from trusted sources.
To use it, you need to add it to the
middlewarearray in yourapp/root.tsxfile.Now, every non-safe request will be validated against CSRF attacks.
If you add this middleware to the root route, it will apply to every route in your application. If your app has API routes that should accept cross-site requests (e.g., for webhooks or third-party integrations), you should move the CSRF middleware to a layout route that wraps only your UI routes, leaving API routes unprotected by CSRF validation.
The middleware uses the
Sec-Fetch-Siteheader to determine request origin. Requests fromsame-originorsame-siteare automatically allowed. Forcross-siterequests, you can specify trusted origins to allow.The request origin is determined by checking (in order):
OriginheaderRefererheaderrequest.referrerpropertyAllowing Cross-Site Requests
You can allow cross-site requests from specific origins using a string:
Or using a RegExp for pattern matching:
Or using an array of strings and RegExps:
Or using a function for dynamic validation:
The function can also be async:
Customizing Safe Methods
By default, the middleware skips CSRF validation for
GET,HEAD, andOPTIONSrequests. You can customize this:Allowing Missing Origin
You can allow requests with missing or invalid origin headers:
Enabling
allowMissingOriginis high risk. When enabled, requests without a parseable origin (missingOrigin/Refererheaders,Sec-Fetch-Siteheader, orOrigin: null) will bypass origin validation entirely. This can allow attackers to perform cross-site requests in environments that don't send origin headers. Only use this option when you're certain that clients without origin headers are within your trusted boundary, or pair it with an additional CSRF token mechanism.Custom Untrusted Request Handler
You can provide a custom handler for requests that fail CSRF validation:
By default, untrusted requests will receive a 403 Forbidden response.
Author
Sergio XalambrÃ