The Firestore security rules we have set up for testimony don't technically block users from re-assigning testimony (by changing the userId of an existing testimony).
I'm not 100% sure how much of a problem this actually is since testimony is a sub-collection under users - not just a field on the testimony data, but we should double-check this to ensure we don't have a security hole.
Summary of the potential problem:
User 123 submits a new testimony with ID ABC
User 123 makes a malicious request to update testimony ABC to have a userId of 456
Testimony ABC now (erroneously) shows up as published by user 456
Success Criteria
Verify that this is an open security hole by making the malicious request
If so, update Firestore security rules so that users can't change the userId/uid of their testimony to that of another user.
Problem
The Firestore security rules we have set up for testimony don't technically block users from re-assigning testimony (by changing the
userIdof an existing testimony).I'm not 100% sure how much of a problem this actually is since testimony is a sub-collection under users - not just a field on the testimony data, but we should double-check this to ensure we don't have a security hole.
Summary of the potential problem:
ABCABCto have a userId of 456ABCnow (erroneously) shows up as published by user 456Success Criteria
userId/uidof their testimony to that of another user.