fix(#349): deny self-writes on members badges subcollection#393
Merged
Aditya948351 merged 1 commit intoMay 31, 2026
Conversation
…s subcollection Any authenticated user could previously write to their own members/<uid>/badges/<badgeId> path because the rule allowed writes when request.auth.uid == userId. Badge logic runs entirely client-side, so this let any user award themselves arbitrary badges with a direct Firestore set call, bypassing all earned-criteria checks. Restrict the allow write condition to isSuperAdmin() only. Badge grants should originate exclusively from trusted backend code (Cloud Functions or Admin SDK) that verifies criteria before writing. The read rule is unchanged. Closes devpathindcommunity-india#349
Aditya948351
approved these changes
May 31, 2026
Collaborator
Aditya948351
left a comment
Aditya948351
left a comment
There was a problem hiding this comment.
Good catch! We definitely don't want users arbitrarily granting themselves badges. This Firestore rule fix is solid.
Collaborator
|
Do star the repo! Successfully merging this and loved the changes you did. |
Aditya948351
added
gssoc26
Contributor
Author
Ofc. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and Why
Closes #349
The
members/{userId}/badges/{badgeId}Firestore rule previously allowed any authenticated user to write badge documents to their own subcollection:Because badge eligibility logic (
determineBadges) runs entirely client-side, this rule let any signed-in user award themselves arbitrary badges (includingearly-adopter,streak-7, and others) by sending a direct Firestoresetcall without meeting any criteria.Change
Removed the
request.auth.uid == userIdbranch so the rule becomes:Badge grants must originate from trusted backend code (Cloud Functions or Admin SDK) that verifies criteria before writing. The
allow readcondition is unchanged.Files Changed
firestore.rules(1 line changed in themembers/{userId}/badges/{badgeId}block)Test Plan
members/<uid>/badges/<anyId>via the Firestore client SDK.GSSoC
program: gssoc