[codex] reject protected admin user updates - #185
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
bbc669e to
0638b9e
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0638b9e9b7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } else if matches!( | ||
| field.as_str(), | ||
| "id" | "email_verified" | ||
| | "created_at" | ||
| | "updated_at" | ||
| | "banned" | ||
| | "ban_reason" | ||
| | "ban_expires" |
There was a problem hiding this comment.
When a deployment uses schema aliases for user columns, this check only rejects the default logical names, but the DB layer accepts both logical and physical field names when resolving updates. For example, if banned is stored as is_banned, a user:update caller can still send data: { "is_banned": true } and bypass the new protection; include the configured schema field names (from context.db_schema / admin schema options) in the protected set before building the update.
Useful? React with 👍 / 👎.
1 participant
Summary
Reject protected user fields in
/admin/update-userso a role with onlyuser:updatecannot mass-assign security-sensitive state such asbanned,banReason,banExpires,emailVerified, timestamps, orid.The existing
rolehandling remains permission-gated byuser:set-role.Root Cause
Finding 6 was valid: the admin update endpoint accepted arbitrary
datafields and passed them through to storage after only special-casingrole. Upstream Better Auth 1.6.9 has the same broad admin update behavior, likely for custom-field compatibility, but it does not apply its normalinput:falseuser-field filtering to the admin endpoint.RustAuth has separate security-sensitive behavior for these fields, including dedicated permissions and ban/session side effects, so this PR hardens RustAuth instead of copying upstream behavior.
Validation
cargo test -p rustauth-plugins --test plugins update_user_rejects_protected_security_fields --all-featurescargo fmt --all --checkcargo clippy --workspace --all-targets --all-features -- -D warningscargo nextest run -p rustauth-plugins --all-featuresgit diff --check