11
31
Fork
You've already forked silverfish
19

Use tower-sec-fetch instead of axum_csrf for CSRF protection #203

Merged
zkat merged 8 commits from kylewlacy/use-tower-sec-fetch-instead-of-csrf into main 2026年01月07日 17:59:04 +01:00
Contributor
Copy link

This spawned from the discussion in #197

This PR replaces all of our existing CSRF machinery (axum_csrf plus our silverfish-middleware-csrf crate) with tower-sec-fetch instead.

The high-level idea is to avoid the classic approaches for CSRF protections (i.e. using cookies and/or random tokens), and to instead rely entirely (or almost entirely) on the Sec-Fetch-* family of request headers. For modern browsers, this protects against CSRF attacks just as well as the classic approaches, but is much simpler to implement (and therefore leaves a lot less room for security vulnerabilities). For more reading, I found these articles really helpful, and used them to guide my implementation:

I used tower-sec-fetch, which-- as the name implies-- gives us a tower layer to check the Sec-Fetch-* headers! But I ended up adding a custom SecFetchAuthorizer too, to tweak the behavior:

Finally, I ripped out all the old CSRF stuff, which was really satisfying! axum_csrf is gone, our custom AuthenticForm / AuthenticMultipart extractors are gone, the entire silverfish-middleware-csrf crate is gone, csrf-salt in the config is gone, all the CSRF token form inputs are gone.

This spawned from the discussion in https://codeberg.org/conjured/silverfish/issues/197 This PR replaces all of our existing [CSRF](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF) machinery ([`axum_csrf`](https://crates.io/crates/axum_csrf) plus our `silverfish-middleware-csrf` crate) with [`tower-sec-fetch`](https://crates.io/crates/tower-sec-fetch) instead. The high-level idea is to avoid the classic approaches for CSRF protections (i.e. using cookies and/or random tokens), and to instead rely entirely (or almost entirely) on the [`Sec-Fetch-*`](https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header) family of request headers. For modern browsers, this protects against CSRF attacks just as well as the classic approaches, but is _much_ simpler to implement (and therefore leaves a lot less room for security vulnerabilities). For more reading, I found these articles really helpful, and used them to guide my implementation: - https://blog.miguelgrinberg.com/post/csrf-protection-without-tokens-or-hidden-form-fields - https://words.filippo.io/csrf/ I used [`tower-sec-fetch`](https://github.com/MatteoJoliveau/tower-sec-fetch), which-- as the name implies-- gives us a `tower` layer to check the `Sec-Fetch-*` headers! But I ended up adding a custom [`SecFetchAuthorizer`](https://docs.rs/tower-sec-fetch/0.1.2/tower_sec_fetch/trait.SecFetchAuthorizer.html) too, to tweak the behavior: - Reject `Sec-Fetch-Site: same-site` requests (redundant if this PR is merged upstream: https://github.com/MatteoJoliveau/tower-sec-fetch/pull/5) - Check by origin as a fallback (if the `Origin` header is set but the `Sec-Fetch-Site` header is not) Finally, I ripped out _all_ the old CSRF stuff, which was really satisfying! `axum_csrf` is gone, our custom `AuthenticForm` / `AuthenticMultipart` extractors are gone, the entire `silverfish-middleware-csrf` crate is gone, `csrf-salt` in the config is gone, all the CSRF token form inputs are gone.
kylewlacy changed title from (削除) kylewlacy/use-tower-sec-fetch-instead-of-csrf (削除ここまで) to Use tower-sec-fetch instead of axum_csrf for CSRF protection 2026年01月07日 11:21:00 +01:00
zkat left a comment
Copy link

omg this PR is so satisfying. This is amazing work, thank you so much! I know this took a lot of sleuthing but this definitely feels like the right thing to do in the end.

omg this PR is so satisfying. This is amazing work, thank you so much! I know this took a lot of sleuthing but this definitely feels like the right thing to do in the end.
@ -231,0 +288,4 @@
// Neither `Sec-Fetch-Site` nor `Origin` are set (this is an old
// browser)! Just defer to whatever the authorization policy allows
// (defaults to allowing the request when no request metadata is found)
tower_sec_fetch::AuthorizationDecision::Continue
Owner
Copy link

Can you make an issue after this to add a banner to our default admin layout area that notifies people when they're visiting with a browser that doesn't send either of these headers, and prompts them to upgrade their browser? I think that would just be a nice thing to do. Not like a popup, literally just a top-area banner warning them that there's a security issue with their current browser.

Can you make an issue after this to add a banner to our default admin layout area that notifies people when they're visiting with a browser that doesn't send either of these headers, and prompts them to upgrade their browser? I think that would just be a nice thing to do. Not like a popup, literally just a top-area banner warning them that there's a security issue with their current browser.
Author
Contributor
Copy link

Done, opened an issue here to track this as a follow-up: #205

Done, opened an issue here to track this as a follow-up: https://codeberg.org/conjured/silverfish/issues/205
Owner
Copy link

also we love a good net-negative PR

also we love a good net-negative PR
zkat deleted branch kylewlacy/use-tower-sec-fetch-instead-of-csrf 2026年01月07日 17:59:05 +01:00
Sign in to join this conversation.
No reviewers
Labels
Clear labels
Compat
Breaking
Breaking change that won't be backward compatible
Flag/Good First Issue
Good issue for first-time contributors
Kind/Accessibility
Accessibility issue, bug or otherwise
Kind/Appearance
Design, styling, and other aesthetic and visual items
Kind/Bug
Something is not working
Kind/Compliance
Legal, policy, or some other kind of compliance
Kind/DevOps
CI/CD, releases, etc
Kind/Documentation
Documentation changes
Kind/Enhancement
Improve existing functionality
Kind/Feature
New functionality
Kind/Performance
Gotta go fast
Kind/Security
This is security issue
Kind/Technical Improvement
Underlying technical improvement that is not necessarily user-impacting or visible.
Kind/Testing
Issue or pull request related to testing
Kind/UX
Related to user experience/product
Priority
Critical
The priority is critical
Priority
High
The priority is high
Priority
Low
The priority is low
Priority
Medium
The priority is medium
Reviewed
Confirmed
Issue has been confirmed
Reviewed
Duplicate
This issue or pull request already exists
Reviewed
Invalid
Invalid issue
Reviewed
Won't Fix
This issue won't be fixed
Size
L
Significant change
Size
M
Medium-size change
Size
S
Small change
Size
XL
Very large change that might take months to complete and impact many components
Size
XS
Trivially small change
Status
Abandoned
Somebody has started to work on this but abandoned work
Status
Blocked
Something is blocking this issue or pull request
Status
Need More Info
Feedback is required to reproduce issue or to continue work
Status
Needs Design
Requires design/review from Alchemists (product/UX)
Status
Needs Discussion
A discussion needs to happen before implementation
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
conjured/silverfish!203
Reference in a new issue
conjured/silverfish
No description provided.
Delete branch "kylewlacy/use-tower-sec-fetch-instead-of-csrf"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?