4 ms·
Agreed, if I understand correctly the fix to this issue would be the following rules inside of a "match" statement in firestore.rules which is plainly documente
by kfarr 2y ago
Agreed, if I understand correctly the fix to this issue would be the following rules inside of a "match" statement in firestore.rules which is plainly documented as firebase firestore security 101:
```
// Allow create new object if user is authenticated
allow create: if request.auth != null;
// Allow update or delete document if user is owner of document
allow update, delete: if request.auth.uid == resource.data.ownerUID
```
- cutemonster 2y agoIs there no Allow-read? Edit: Yes, allow read, update, delete: if request.auth != null && request.auth.uid == userId;
- GVRV 2y agoDidn't they already have these rules in place? And the vulnerability was when the owner was updating the resource to have a new owner?
- kfarr 2y agoUnclear if they had these rules in place already but I'm curious... If the rule permits writing when the userid matches, presumably there is nothing stopping the write operation to change the userid value, to your point. Which then leads me to the next question, what is the practical way to write rules against that operation?
- GVRV 2y agoIn my limited experience, I've seen it handled by adding the user's ID in the path of any resource that belongs to a particular user, so that the user ID from the resource path can be compared with the authenticated user ID as a security rule condition. But as expected, you can validate the incoming data as well https://firebase.google.com/docs/firestore/security/rules-conditions#data_validation https://firebase.google.com/docs/firestore/security/rules-co... but this would need to be done for any attribute that might lead to a change of ownership.