// docs / baas security / firebase if-true explainer

Giải thích Firebase allow read, write: if true: nó làm gì và cách sửa

Q: Sự khác biệt giữa if true và if request.auth != null là gì?

if true cho phép truy cập ẩn danh — bất kỳ ai trên internet. if request.auth != null yêu cầu bất kỳ người dùng đã đăng nhập nào, tốt hơn nhưng vẫn sai: bất kỳ người dùng nào của ứng dụng đều có thể đọc dữ liệu của mọi người dùng khác. Rules production phải giới hạn theo người dùng hoặc tổ chức cụ thể qua request.auth.uid == resource.data.owner_uid hoặc tương tự.

Q: Firebase có bao giờ tự động hết hạn rules if true không?

Các dự án cũ (trước 2023) có hẹn giờ 30 ngày chuyển rules if true thành if false. Dự án hiện tại không có — rule tồn tại vô thời hạn cho đến khi được thay thế thủ công. Nếu bạn tạo dự án trước 2023 và rules của bạn trông ổn, hãy kiểm tra kỹ: hẹn giờ có thể đã lật chúng thành if false, điều này chặn chính ứng dụng của bạn.

Q: Điều gì xảy ra nếu ứng dụng của tôi thực sự là công khai đọc (blog, danh mục sản phẩm)?

Vậy hãy viết rõ ràng allow read: if true; allow write: if false; chỉ trên collection công khai — không phải trên mọi collection trong cơ sở dữ liệu. Dùng một mệnh đề match riêng cho mỗi collection và không bao giờ dùng ký tự đại diện đệ quy '{'document=**'}' trên các rules có thể ghi.

<code>allow read, write: if true;</code> là cấu hình sai Firebase phổ biến nhất trong production. Đó là mặc định chế độ thử nghiệm mà Firebase Console đề xuất khi bạn tạo một cơ sở dữ liệu mới, rule mà các công cụ AI lập trình tạo lại từ tài liệu, và rule mở toàn bộ cơ sở dữ liệu Firestore của bạn cho bất kỳ ai trên internet. Bài viết này giải thích cú pháp chính xác, cho thấy những gì kẻ tấn công thấy khi rule này hoạt động, và cung cấp cho bạn bốn bản thay thế nghiêm ngặt dần phù hợp với các trường hợp dùng khác nhau.

Cú pháp, từng dòng

Một tài liệu rules Firestore chế độ thử nghiệm hoàn chỉnh có sáu dòng:

firebase

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Giải mã:

rules_version = '2'; chọn engine rules v2 (hiện hành). Rules v1 cũ đã không còn được dùng.
service cloud.firestore giới hạn khối cho Firestore. Realtime Database dùng cú pháp JSON khác; Cloud Storage dùng service firebase.storage.
match /databases/{database}/documents liên kết cơ sở dữ liệu (default) đặc biệt (hầu hết dự án chỉ có một).
match /{document=**} là ký tự đại diện đệ quy. ** khớp bất kỳ đường dẫn nào ở bất kỳ độ sâu nào. Kết hợp với {document}, điều này bắt mọi document trong mọi collection — một mệnh đề match duy nhất chi phối toàn bộ cơ sở dữ liệu.
allow read, write: if true; là thân rule. Cả read và write đều được phép; điều kiện if true luôn đúng. read bao gồm các thao tác get và list; write bao gồm create, update và delete.

Hiệu ứng ròng: bất kỳ client nào có Firebase project ID và đúng SDK đều có thể đọc hoặc ghi bất kỳ document nào trong bất kỳ collection nào. Không yêu cầu xác thực. Không thực thi giới hạn tốc độ.

Vì sao Firebase ship cái này làm mặc định

Firebase muốn bạn coding trong 30 giây đầu tiên sau khi tạo dự án. Lựa chọn thay thế — bắt bạn viết một rule chính xác trước khi bất kỳ thao tác đọc hoặc ghi nào hoạt động — sẽ chặn quá trình onboarding. Vì vậy Console cung cấp hai tùy chọn khi bạn tạo cơ sở dữ liệu: Production mode (từ chối mọi thứ, bạn viết rules) hoặc Test mode (cho phép mọi thứ trong 30 ngày). Hầu hết developer nhấp test mode rồi quên ghé lại. Các dự án cũ có hẹn giờ 30 ngày; dự án hiện tại có rule if true không có thời hạn tự động hết hạn.

Vấn đề cấu trúc: các công cụ AI lập trình huấn luyện trên tài liệu, hướng dẫn và câu trả lời Stack Overflow hiển thị rules chế độ thử nghiệm. Khi bạn hỏi Cursor hoặc Claude Code "làm thế nào để thiết lập Firebase", câu trả lời thường bao gồm khối allow read, write: if true chính xác như thể nó là rule production. AI không biết — và không được nhắc để biết — rằng rule này không an toàn cho production.

Những gì kẻ tấn công thấy

Cụ thể, một kẻ tấn công biết Firebase project ID của bạn (có thể trích xuất từ bundle của bất kỳ ứng dụng đã triển khai nào trong 30 giây) và chạy đoạn sau có thể liệt kê mọi document trong mọi collection:

Một yêu cầu curl chưa xác thực duy nhất là đủ để liệt kê mọi collection. Xem khối được tô sáng bên dưới.

bash

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

Phản hồi là danh sách đầy đủ các collection cấp cao nhất. Với mỗi collection, một yêu cầu thứ hai trả về documents. Không có giới hạn tốc độ trên đường dẫn này vì rules if true chấp nhận lưu lượng ẩn danh. Chúng tôi đã thấy cơ sở dữ liệu Firebase với hàng triệu documents bị liệt kê trong chưa đến một giờ.

Về đường ghi: một POST duy nhất với {fields} tạo một document mới. Kẻ tấn công có thể làm ô nhiễm collections của bạn với rác, làm xấu các trang giao diện người dùng đọc từ Firestore hoặc dùng cơ sở dữ liệu của bạn làm message broker miễn phí — hóa đơn sử dụng của bạn tăng vọt, bạn điều tra, hóa đơn giải thích vấn đề.

Bốn bản thay thế an toàn cho production

Chọn bản thay thế khớp với mô hình dữ liệu của ứng dụng. Cả bốn đều giả định bạn có xác thực người dùng (Firebase Auth hoặc bất kỳ nhà cung cấp nào phát hành Firebase ID token):

Tùy chọn 1: Documents thuộc sở hữu người dùng

Mẫu SaaS phổ biến nhất. Documents nằm dưới /users/{userId}/... và chỉ chủ sở hữu mới có thể chạm vào. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Tùy chọn 2: Trường owner trên mọi document

Khi documents nằm trong các collection phẳng (không lồng dưới user ID), lưu một trường owner_uid và kiểm tra nó. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

firebase

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

Tùy chọn 3: Cô lập đa tổ chức

Cho B2B SaaS với dữ liệu phạm vi tổ chức. Lưu trường org_id trên mọi document và kiểm tra nó với custom claim của người dùng. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Yêu cầu đặt custom claim khi đăng ký qua Firebase Admin SDK.

firebase

allow read, write: if request.auth.token.org_id == resource.data.org_id;

Tùy chọn 4: Nội dung công khai chỉ đọc

Cho nội dung marketing, hồ sơ công khai, danh mục sản phẩm — bất cứ thứ gì thực sự là công khai đọc nhưng chỉ admin ghi. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Custom claim admin chỉ được đặt trên các tài khoản admin.

firebase

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Truy vấn kiểm toán nhanh

Trước khi sửa, kiểm tra xem if true có thực sự đang hoạt động không. Mở Firebase Console → Firestore → Rules và tìm if true. Nếu bạn tìm thấy nó ở bất kỳ đâu ngoài một comment, bạn có một phát hiện rule mở. Trình mô phỏng Rules trong cùng UI cho phép bạn phát lại yêu cầu của kẻ tấn công cục bộ — dán một GET /users/somebody ẩn danh và xác nhận trình mô phỏng trả về Allowed.

Xác nhận từ bên ngoài: chạy một lượt quét FixVibe với URL production của bạn. Check baas.firebase-rules thăm dò rules Firestore, Realtime Database và Storage của bạn và báo cáo cùng phát hiện mà một kẻ tấn công sẽ phát hiện — độc lập với những gì Firebase Console hiển thị.

Câu hỏi thường gặp

Sự khác biệt giữa <code>if true</code> và <code>if request.auth != null</code> là gì?

if true cho phép truy cập ẩn danh — bất kỳ ai trên internet. if request.auth != null yêu cầu bất kỳ người dùng đã đăng nhập nào, tốt hơn nhưng vẫn sai: bất kỳ người dùng nào của ứng dụng đều có thể đọc dữ liệu của mọi người dùng khác. Rules production phải giới hạn theo người dùng hoặc tổ chức cụ thể qua request.auth.uid == resource.data.owner_uid hoặc tương tự.

Firebase có bao giờ tự động hết hạn rules <code>if true</code> không?

Các dự án cũ (trước 2023) có hẹn giờ 30 ngày chuyển rules if true thành if false. Dự án hiện tại không có — rule tồn tại vô thời hạn cho đến khi được thay thế thủ công. Nếu bạn tạo dự án trước 2023 và rules của bạn trông ổn, hãy kiểm tra kỹ: hẹn giờ có thể đã lật chúng thành if false, điều này chặn chính ứng dụng của bạn.

Tôi có thể dùng một kiểm tra timestamp ngày tương lai làm lưới an toàn không?

Không — điều kiện timestamp không phải là biện pháp kiểm soát bảo mật. Nó hết hạn rule mở vào một ngày tương lai, có nghĩa là cho đến ngày đó kẻ tấn công có quyền truy cập đầy đủ. Và bạn sẽ quên ngày đó. Hãy thay thế if true bằng một rule giới hạn theo xác thực, không phải bằng một rule giới hạn thời gian.

Điều gì xảy ra nếu ứng dụng của tôi thực sự là công khai đọc (blog, danh mục sản phẩm)?

Vậy hãy viết rõ ràng allow read: if true; allow write: if false; chỉ trên collection công khai — không phải trên mọi collection trong cơ sở dữ liệu. Dùng một mệnh đề match riêng cho mỗi collection và không bao giờ dùng ký tự đại diện đệ quy {document=**} trên các rules có thể ghi.

Các bước tiếp theo

Chạy một lượt quét FixVibe với URL production của bạn — check baas.firebase-rules xác nhận xem if true có hiện đang khai thác được từ internet công khai không. Để biết cơ chế scanner và các phát hiện song song cho Realtime Database và Storage, xem Firebase rules scanner. Để biết lớp cấu hình sai tương đương trên Supabase, đọc Supabase RLS scanner.