The sec_fetch_site_csrf plugin should be considered safe-enough

[rosenfeld]

Here's what the documentation currently says about this plugin:

The protection offered by the sec_fetch_site plugin is weaker than the protection offered by the route_csrf plugin with default settings, since it doesn’t support per-request tokens.

Why per-request tokens would make it any safer? The main reason to mask or replace the CSRF token is to prevent against BREACH attacks but by using the Sec-Fetch-Site header as a CSRF protection mechanism the app won't be vulnerable to BREACH since there's no token to be reflected.

Per-request tokens can work well on traditional HTTP apps where a user is presented a form, submits a button, gets another page and so on, all on a single tab session. It doesn't work well for SPA apps performing POST requests concurrently, for example.

Sec-Fetch-Site has been implemented since 2023 in all relevant browsers, 3 years ago. It's not only much simpler to implement, but it's also faster to process and pretty safe to use. It's not sucsectible to BREACH attacks either. And yet the documentation currently describes it almost as an unsafe method to prevent CSRF, while it should be considered the preferred approach IMO these days.

Be aware you are trading security for simplicity when using the sec_fetch_site plugin instead of the route_csrf plugin. Other caveats in using the sec_fetch_site plugin:

• Not all browsers set the Sec-Fetch-Site header. Some browsers didn’t start setting the header until 2023. In these cases, you need to decide how to handle the request. The default is to deny the request, though you can use the :allow_missing option to allow it.

• Sec-Fetch-Site headers are not set for http requests, only https requests, so this doesn’t offer protection for http requests.

• It isn’t possible to share a CSRF secret between applications in different origins to allow cross-site requests between the applications.

I don't really see any security trades, or at least they're not explained well enough. For example, if the CSRF token doesn't change, the attacker must know the token in order to perform any POST requests to the server. How could the attacker know about the user's CSRF token? I can only think of some XSS vulnerability allowing the attacker to inspect the CSRF token. If such vulnerability exists, the application has bigger problems to worry about. Also, if it exists, the attacker would be able to read the token from the form anyway no matter if it's unique for that request.

The first point was relevant in 2023, but I don't think it remains relevant in 2026, 3 years later. See:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site#browser_compatibility

If your app is deployed over HTTP instead of HTTPS, you can't be serious about security either. There's no reason for HTTPS not to be used for all apps these days.

I'd say that if your application would want to be accessible by other sites from other domains, then it might be a use case for preferring route_csrf over sec_fetch_site_csrf. However, if the third-party application on a separate domain should be allowed to talk to the Roda server, maybe it would make more sense for the backend to adopt JWT token authentication instead of a cookie-based one. Anyway, the route_csrf plugin would be only one of the available options to allow for apps to share a given CSRF token. Most likely there are better solutions available for such cases, that should be investigated on a case-per-case basis. This is not a common-enough pattern in order to justify preferring route_csrf over sec_fetch_site_csrf.

I'd love to hear your thoughts about it.

[jeremyevans]

Here's what the documentation currently says about this plugin:

The protection offered by the sec_fetch_site plugin is weaker than the protection offered by the route_csrf plugin with default settings, since it doesn’t support per-request tokens.

Why per-request tokens would make it any safer? The main reason to mask or replace the CSRF token is to prevent against BREACH attacks but by using the Sec-Fetch-Site header as a CSRF protection mechanism the app won't be vulnerable to BREACH since there's no token to be reflected.

Per-request tokens are safer because they ensure that a user cannot successfully submit a request to an endpoint unless they have been provided a per-request token for that endpoint. Without per-request tokens, users can successfully submit a request to any endpoint, since the CSRF token is the same for all endpoints.

Admittedly, the extra security goes beyond what you would typically think of as CSRF protection. Traditional CSRF protection focuses on protecting users from forms on other websites. Per-request tokens provide protection against users accessing things they were not explicitly given access to on the site itself.

Per-request tokens can work well on traditional HTTP apps where a user is presented a form, submits a button, gets another page and so on, all on a single tab session. It doesn't work well for SPA apps performing POST requests concurrently, for example.

Certainly it is easier to use per-request tokens on traditional apps. It's possible to use them with SPAs as long as you provide the per-request tokens appropriately for the SPA to use, though it is more work (SPAs in general are more work).

I don't really see any security trades, or at least they're not explained well enough. For example, if the CSRF token doesn't change, the attacker must know the token in order to perform any POST requests to the server. How could the attacker know about the user's CSRF token? I can only think of some XSS vulnerability allowing the attacker to inspect the CSRF token. If such vulnerability exists, the application has bigger problems to worry about. Also, if it exists, the attacker would be able to read the token from the form anyway no matter if it's unique for that request.

As explained above, per-request tokens offer additional protection, though the protection may be considered as going beyond traditional CSRF protection.

The first point was relevant in 2023, but I don't think it remains relevant in 2026, 3 years later. See:

I think it's still relevant, even if it isn't as relevant now as it was then. Can I use shows Global 93.47% for Sec-Fetch-Site, so support is far from universal: https://caniuse.com/?search=Sec-Fetch-Site

I'd say that if your application would want to be accessible by other sites from other domains, then it might be a use case for preferring route_csrf over sec_fetch_site_csrf. However, if the third-party application on a separate domain should be allowed to talk to the Roda server, maybe it would make more sense for the backend to adopt JWT token authentication instead of a cookie-based one. Anyway, the route_csrf plugin would be only one of the available options to allow for apps to share a given CSRF token. Most likely there are better solutions available for such cases, that should be investigated on a case-per-case basis. This is not a common-enough pattern in order to justify preferring route_csrf over sec_fetch_site_csrf.

I'd love to hear your thoughts about it.

IMO, the security benefits of route_csrf are significant. I've seen multiple production cases that would have been actual security vulnerabilities were it not for the security provided by per-request CSRF tokens. Traditional CSRF tokens also work in all browsers. So I think the existing documentation is good. If you have additional questions or think additional changes are needed considering the above, please let me know.

[rosenfeld]

Thanks for the response, that clarifies a lot. I'd say this is exactly what's missing on the documentation. Some note like:

"route_csrf" protection goes beyond just CSRF protection. It also protects your app from unauthorized requests by not allowing the same token to be shared across multiple requests. It ensures each token can be used only once.

On the other side, for the sec_fetch_site_csrf, it would help to better explain which cases it would be better suited and which cases route_csrf would be better suited. Maybe some different documentation file shared by both plugin documentation.

Here's my understanding:

sec_fetch_site_csrf: more suitable if you care about strict CSRF protection, you're targetting recent browsers, and prefer a simpler and faster approach supporting concurrent requests, which can be common in client-side requests such as those performed by SPA, PWA etc.

route_csrf: more suitable if besides protecting against CSRF you want to enforce a single request authorization (CSRF token) per presented form or similar workflows, and don't want to allow the token to be reused.

Not sure if this would be the best wording around it but you got the idea. I particularly feel that too much fear is being currently put on the sec_fetch_site_csrf plugin and that it's not really necessary or desirable.

I've already adopted the Sec-Fetch-Site approach by the way in my new app, so this discussion is only about the documentation of the plugins. I think both plugins are great and they shouldn't change, I'm just worried about how they are advertised in the documentation.

[jeremyevans]

I think the sec_fetch_site_csrf plugin documentation is accurate and reflects the tradeoffs involved. I don't want to encourage the use of sec_fetch_site_csrf over route_csrf. Someone new to both approaches should probably use route_csrf until they have a understanding of tradeoffs involved.

I'm not sure why you think sec_fetch_site_csrf would be better for concurrent requests, or why you think it is stricter. What concurrency issues do you think are present in the route_csrf approach? Why do you think the Sec-Fetch-Site approach is stricter?

In terms of performance, if you can provide a benchmark showing route_csrf is measurably slower for a real world scenario, I'd be fine changing "trading security for simplicity" to "trading security for simplicity and performance".

[rosenfeld]

I said it offered strict protection against CSRF because it doesn't attempt to provide extra layers of protection such as route_csrf. English is not my first language so maybe there's a better way to state that.

Imagine your SPA automatically publish errors to your Roda app (instead of Bugsnag, for example). Imagine multiple errors happened about the same time upon a user action. In that case, 2 concurrent requests were posted to the Roda app. If a single CSRF token is valid for the current session at a given time, this is not going to work well. If the same masked CSRF token is used (the Rails approach, for instance) both errors are reported to the backend. Same if Sec-Fetch-Site is used. But if the documentation doesn't explain the trade-offs very clearly the user may believe that they should use route_csrf if they don't understand the trade-offs. If the documentation clearly explains how each method works, they can more easily decide which approach they want to take for their apps.

SecureRandom (used to generate new tokens upon each request) are expensive, especially when running on limited hardware such as the e2-micro instance on GCP. If the traffic is high, it can greatly reduce the max throughput. But anyway, I'm not advocating for changing that snippet to include "performance", I don't think this is the strong reason behind the decision on which method to adopt for the Roda app.

[jeremyevans]

I said it offered strict protection against CSRF because it doesn't attempt to provide extra layers of protection such as route_csrf. English is not my first language so maybe there's a better way to state that.

When comparing sec_fetch_site_csrf to route_csrf, stating sec_fetch_site_csrf provides strict CSRF protection implies that route_csrf either doesn't provide strict protection, or the protection provided by sec_fetch_site_csrf is somehow more strict. I think you want to give the impression that sec_fetch_site_csrf is strictly (only) CSRF protection, as opposed to the route_csrf plugin, which builds additional protection on top of the typical CSRF protection. But unfortunately, the wording unintentionally implies something negative about route_csrf.

Imagine your SPA automatically publish errors to your Roda app (instead of Bugsnag, for example). Imagine multiple errors happened about the same time upon a user action. In that case, 2 concurrent requests were posted to the Roda app. If a single CSRF token is valid for the current session at a given time, this is not going to work well.

route_csrf CSRF tokens are generally valid for an entire session, they are not time-limited. So both concurrent requests should work fine with route_csrf, assuming the token for each is valid.

If the same masked CSRF token is used (the Rails approach, for instance) both errors are reported to the backend. Same if Sec-Fetch-Site is used. But if the documentation doesn't explain the trade-offs very clearly the user may believe that they should use route_csrf if they don't understand the trade-offs. If the documentation clearly explains how each method works, they can more easily decide which approach they want to take for their apps.

The sec_fetch_site_csrf plugin states that it uses the Sec-Fetch-Site header. I don't think it's the purpose of the documentation to explain what the Sec-Fetch-Site header does, as there are other resources that would do a better job. The route_csrf plugin describes how the plugin works, even giving detail about how the token is constructed. I'm not sure more detail is needed for either, considering the source code is available.

SecureRandom (used to generate new tokens upon each request) are expensive, especially when running on limited hardware such as the e2-micro instance on GCP. If the traffic is high, it can greatly reduce the max throughput. But anyway, I'm not advocating for changing that snippet to include "performance", I don't think this is the strong reason behind the decision on which method to adopt for the Roda app.

For the typical database-backed web application, these calls are not likely to be a bottleneck. I agree with you that performance is unlikely to be a significant concern when deciding between the two approaches.

[rosenfeld]

Yes, I meant strictly, thanks for the explanation. I just got a first impression, while reading about the sec approach that it wasn't sufficiently safe to protect against CSRF.