How can I securely duplicate and delete user profiles with Firestore rules in React Native?

Below is an analysis of your rules and potential vulnerabilities, along with some advice on how to approach your duplication case.

---

Potential Vulnerabilities

1. Overly Broad Read Permissions

   • Your rule:

     FIRESTORECopied
     allow read: if request.auth != null;

     This means every authenticated user can read all user profiles. If you intend for each user’s data to be private, you should restrict reads to the owning user (for example, by checking that the user’s UID matches the document owner).

2. Inadequate Delete Protection in the Original Rule

   • Your original rule allowed delete on all documents as long as the user was authenticated:

     FIRESTORECopied
     allow delete: if request.auth != null;

     This lets any authenticated user delete any user document. In a secure setup, deletion should verify that the authenticated user is the owner (e.g. checking request.auth.uid == resource.data.id and/or matching the document ID).

3. Duplication Failing the Ownership Check

   • In your edited rules the create operation enforces:

     FIRESTORECopied
     allow create: if request.auth != null &&
                    request.auth.uid == request.resource.data.id &&
                    request.auth.uid == userId;

     When you duplicate the document, you’re renaming it (for example to "Dupe:<uid>"). Since userId now becomes something like "Dupe:<uid>" while request.auth.uid is still <uid>, the check fails. This is a security feature that prevents you from creating a document with an ID that doesn’t match the authenticated user’s UID.

---

Evaluating Security vs. Functionality

• Enforcing Owner Checks:
  It’s great practice that both your create and update rules enforce that:

  • The document data contains the correct owner ID (request.resource.data.id or a custom “owner” field).
  • The document’s ID (or path variable userId) matches the authenticated user’s UID.

• Duplication Process:
  The failure in duplication is a side effect of your security design rather than a security hole. Allowing a document with a manipulated ID (e.g. prepending "Dupe:") would permit a user to write data into another “user’s” document, which is precisely what you’re trying to prevent.

---

Recommendations

1. Refine Read Permissions:
   If user data should remain private, consider limiting read access to the owner. For example:

   FIRESTORECopied
   match /users/{userId} {
     // Only allow the owner to read their data
     allow read: if request.auth != null && request.auth.uid == userId;
     // ... rest of your rules
   }

2. Secure Delete Operations:
   Make sure delete operations also check that the authenticated user is the owner. For example, using:

   FIRESTORECopied
   allow delete: if request.auth != null &&
                  request.auth.uid == resource.data.id &&
                  request.auth.uid == userId;

3. Handling Duplication:
   Since you want to duplicate a user profile and then delete the original, you have a couple of options to meet security requirements without weakening them:

   • Use a Separate Collection for Duplicates:
     Instead of placing the duplicate in the same users collection, consider writing it to a different collection (e.g. duplicated_users). You can then write security rules appropriate for that collection.

   • Apply a Custom Field for Document Ownership:
     Rather than using the document ID to enforce ownership, add a field such as owner (or author_uid) in the document data. Your rules would then verify that request.auth.uid == request.resource.data.owner (and similarly for updates and deletes). If you need to duplicate the document with a new document ID (like "Dupe:<uid>"), you would still keep owner: <uid> in the document. For example:

     FIRESTORECopied
     match /users/{userId} {
       allow create: if request.auth != null &&
                     request.auth.uid == request.resource.data.owner;
       allow update: if request.auth != null &&
                     request.auth.uid == resource.data.owner &&
                     request.auth.uid == request.resource.data.owner;
       allow delete: if request.auth != null &&
                     request.auth.uid == resource.data.owner;
       // Optionally, allow read only to the owner:
       allow read: if request.auth != null && request.auth.uid == resource.data.owner;
     }

     This way, even if the document ID changes, the ownership is still enforced by the data field.

4. Duplication Code Changes:
   With the approach above, your duplication code could remain largely the same but ensure that the owner field is maintained. For example:

   JAVASCRIPTCopied
   // Assume deleteUserData contains a key "owner" that equals user.uid
   const dupeUser = doc(firestore, 'users', `Dupe:${user?.uid}`);
   await setDoc(dupeUser, deleteUserData);

   Since deleteUserData.owner still equals user.uid, the create rule would pass.

---

Summary

• Vulnerabilities:
  • Unrestricted read access to all user documents.
  • Delete rule is too permissive (in the original rules).
  • Difficulty with duplication is a result of checking that the document ID equals the auth UID—protecting data integrity.
• Approach:
  Consider using a dedicated field (e.g. owner or author_uid) to enforce ownership rather than relying solely on the document’s ID. Alternatively, placing duplicated documents in a separate collection can help align your functional needs with strong security rules.

By balancing the need for functionality (such as duplication) against strict ownership checks, you can maintain a secure environment for your Expo app.