Firebase技术咨询：如何保护文档creation_date属性不被篡改与非法修改

Great question—this is a super common scenario when building with Firestore, and the fix hinges on combining Firebase Security Rules with the built-in server timestamp functionality to lock down that field properly. Let’s break this down into two key goals: preventing fake dates on creation, and blocking edits to the field afterward.

1. Prevent Fake creation_date on Document Creation #

The key here is ensuring the creation_date is always set by Firestore’s server, not the client. Even if you use ServerValue.TIMESTAMP in your client code, a malicious user could reverse-engineer your app and send a custom date instead. Security rules are your first line of defense here.

Here’s how to enforce that the creation_date either isn’t provided by the client (so Firestore fills it with the server timestamp) or exactly matches Firestore’s server time (request.time):

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /your_collection/{docId} {
      // Allow document creation only if creation_date is server-generated
      allow create: if 
        (!('creation_date' in request.resource.data) || 
        request.resource.data.creation_date == request.time);
      
      // Add your read/delete rules here based on your auth setup
      allow read: if true; // Adjust this to your actual authentication requirements
    }
  }
}

Why this works: #

• request.time is a server-side value that clients can’t forge. If a user tries to send a fake date, it won’t match request.time, and the rule will block the write.
• If your client code uses FieldValue.serverTimestamp() (or ServerValue.TIMESTAMP for older SDKs), the client sends a placeholder that Firestore replaces with request.time—which will pass the rule.

2. Block Subsequent Edits to creation_date #

Once the document is created, you need to make sure no one can change the creation_date later. Add an update rule that prevents modifying the field:

Update the rules to include this:

allow update: if 
  !('creation_date' in request.resource.data) || 
  request.resource.data.creation_date == resource.data.creation_date;

Why this works: #

• resource.data refers to the existing document data. The rule says either the update doesn’t include creation_date at all, or if it does, it’s exactly the same as the original value (so no change happens).

Client-Side Best Practice #

While security rules are mandatory, you should also enforce good practice in your client code to avoid accidental issues:

• Always use Firestore’s built-in server timestamp method when creating documents. For example, in JavaScript:

  import { doc, setDoc, serverTimestamp } from "firebase/firestore";
  
  await setDoc(doc(db, "your_collection", "new_doc"), {
    // Your other fields here
    creation_date: serverTimestamp()
  });
  

• Never let users input or modify the creation_date field in your UI—hide it entirely from any edit forms.

Remember: Client-side checks are for user experience, not security. A determined user can bypass them, so your security rules are the critical safeguard here.

内容的提问来源于stack exchange，提问作者rendom