Danh sách kiểm tra bảo mật của Firebase

Để giữ cho các tài nguyên Firebase và dữ liệu của người dùng được an toàn, hãy làm theo các nguyên tắc sau. Không phải mục nào cũng nhất thiết áp dụng cho các yêu cầu của bạn, nhưng hãy lưu ý khi phát triển ứng dụng.

Tránh lưu lượng truy cập độc hại

Thiết lập tính năng giám sát và cảnh báo cho các dịch vụ phụ trợ

Để phát hiện lưu lượng truy cập độc hại, chẳng hạn như các cuộc tấn công từ chối dịch vụ (DOS), hãy thiết lập tính năng giám sát và cảnh báo cho Cloud Firestore, Realtime Database, Cloud Storage, và Hosting

Nếu nghi ngờ ứng dụng của mình bị tấn công, hãy liên hệ với Nhóm hỗ trợ càng sớm càng tốt để cho họ biết chuyện gì đang xảy ra.

Bật App Check

Để đảm bảo chỉ ứng dụng của bạn mới có thể truy cập vào các dịch vụ phụ trợ, hãy bật tính năng Firebase App Check cho mọi dịch vụ hỗ trợ tính năng này.

Định cấu hình Cloud Functions để mở rộng quy mô cho lưu lượng truy cập thông thường

Cloud Functions tự động mở rộng quy mô để đáp ứng nhu cầu của ứng dụng, nhưng trong trường hợp bị tấn công, điều này có thể dẫn đến hoá đơn rất lớn. Để ngăn chặn điều này, bạn có thể giới hạn số lượng phiên bản đồng thời của một hàm dựa trên lưu lượng truy cập thông thường cho ứng dụng.

Thiết lập tính năng cảnh báo để được thông báo khi gần đạt đến giới hạn

Nếu dịch vụ của bạn có mức sử dụng tăng đột biến, thì hạn mức thường sẽ được áp dụng và tự động điều tiết lưu lượng truy cập vào ứng dụng. Hãy nhớ theo dõi trang tổng quan Mức sử dụng và thanh toán dashboard, nhưng bạn cũng có thể đặt cảnh báo về ngân sách cho dự án để được thông báo khi mức sử dụng tài nguyên vượt quá dự kiến.

Ngăn chặn tình trạng tự gây ra lỗi DOS: kiểm thử các hàm cục bộ bằng trình mô phỏng

Bạn có thể dễ dàng vô tình tự gây ra lỗi DoS khi phát triển Cloud Functions: ví dụ: bằng cách tạo một vòng lặp ghi kích hoạt vô hạn. Bạn có thể ngăn những lỗi này ảnh hưởng đến các dịch vụ đang hoạt động bằng cách thực hiện phát triển bằng Firebase Local Emulator Suite.

Và nếu bạn vô tình tự gây ra lỗi DOS, hãy huỷ triển khai hàm bằng cách xoá hàm đó khỏi index.js và sau đó chạy firebase deploy --only functions.

Khi khả năng phản hồi theo thời gian thực ít quan trọng hơn, hãy cấu trúc các hàm một cách phòng thủ

Nếu không cần trình bày kết quả của một hàm theo thời gian thực, bạn có thể giảm thiểu lưu lượng truy cập độc hại bằng cách xử lý kết quả theo lô: phát hành kết quả vào một Pub/Sub chủ đề và xử lý kết quả theo khoảng thời gian đều đặn bằng một hàm đã lên lịch.

Tìm hiểu về khoá API

Khoá API cho các dịch vụ Firebase không phải là bí mật

Khoá API cho các dịch vụ Firebase chỉ xác định dự án và ứng dụng Firebase của bạn đối với các dịch vụ đó. Quy trình uỷ quyền được xử lý thông qua Google Cloud các quyền IAM, Firebase Security Rules, và Firebase App Check.

Tất cả khoá API do Firebase cung cấp đều tự động bị hạn chế đối với các API liên quan đến Firebase. Nếu quá trình thiết lập ứng dụng của bạn tuân theo các nguyên tắc trên trang này, thì khoá API bị hạn chế đối với các dịch vụ Firebase không cần được coi là bí mật và bạn có thể đưa các khoá này vào mã hoặc tệp cấu hình một cách an toàn.

Thiết lập các quy tắc hạn chế đối với khoá API

Nếu bạn sử dụng khoá API cho các dịch vụ khác của Google, hãy đảm bảo rằng bạn áp dụng các quy tắc hạn chế đối với khoá API để giới hạn phạm vi khoá API cho các ứng dụng của bạn và các API mà bạn sử dụng.

Chỉ sử dụng khoá API do Firebase cung cấp chỉ cho các API liên quan đến Firebase. Nếu ứng dụng của bạn sử dụng bất kỳ API nào khác (ví dụ: API Địa điểm cho Maps hoặc Gemini Developer API), hãy sử dụng khoá API riêng và hạn chế khoá đó đối với API áp dụng.

Giữ bí mật khoá máy chủ FCM

Không giống như khoá API cho các dịch vụ Firebase, khoá máy chủ FCM (do HTTP API FCM cũ sử dụng) là thông tin nhạy cảm và phải được giữ bí mật.

Giữ bí mật khoá tài khoản dịch vụ

Không giống như khoá API cho các dịch vụ Firebase, khoá riêng tư của tài khoản dịch vụ (do Firebase Admin SDK) là thông tin nhạy cảm và phải được giữ bí mật.

Firebase Security Rules

Khởi chạy các quy tắc ở chế độ chính thức hoặc chế độ khoá

Khi thiết lập Cloud Firestore, Realtime Database, và Cloud Storage, hãy khởi chạy Firebase Security Rules để từ chối mọi quyền truy cập theo mặc định và thêm các quy tắc cấp quyền truy cập vào các tài nguyên cụ thể khi bạn phát triển ứng dụng.

Sử dụng một trong các chế độ cài đặt mặc định cho các phiên bản mới của Cloud Firestore (chế độ chính thức ) và Realtime Database (chế độ khoá). Đối với Cloud Storage, hãy bắt đầu với một cấu hình quy tắc bảo mật như sau:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

Quy tắc bảo mật là một lược đồ; thêm quy tắc khi bạn thêm tài liệu

Đừng viết quy tắc bảo mật sau khi viết ứng dụng, như một loại công việc trước khi phát hành. Thay vào đó, hãy viết quy tắc bảo mật khi bạn viết ứng dụng, coi các quy tắc này như một giản đồ cơ sở dữ liệu: bất cứ khi nào bạn cần sử dụng một loại tài liệu hoặc cấu trúc đường dẫn mới, hãy viết quy tắc bảo mật cho loại tài liệu hoặc cấu trúc đường dẫn đó trước.

Kiểm thử đơn vị các quy tắc bảo mật bằng Local Emulator Suite; thêm vào CI

Để đảm bảo các quy tắc bảo mật của bạn theo kịp quá trình phát triển ứng dụng, hãy kiểm thử đơn vị các quy tắc bằng Firebase Local Emulator Suite và thêm các bài kiểm thử này vào quy trình CI. Xem các hướng dẫn này cho Cloud Firestore và Realtime Database.

Xác thực

Xác thực tùy chỉnh: đúc JWT từ một môi trường đáng tin cậy (phía máy chủ)

Nếu đã có một hệ thống đăng nhập an toàn (hệ thống tuỳ chỉnh hoặc dịch vụ của bên thứ ba), bạn có thể sử dụng hệ thống hiện có để xác thực với các dịch vụ Firebase. Tạo JWT tuỳ chỉnh từ một môi trường đáng tin cậy, sau đó truyền mã thông báo đến ứng dụng, ứng dụng này sẽ sử dụng mã thông báo để xác thực (iOS+, Android, Web, Unity, C++).

Để xem ví dụ về cách sử dụng tính năng xác thực tuỳ chỉnh với nhà cung cấp bên thứ ba, hãy xem bài đăng trên blog, Xác thực bằng Firebase bằng Okta.

Xác thực được quản lý: nhà cung cấp OAuth 2.0 là an toàn nhất

Nếu bạn sử dụng các tính năng xác thực được quản lý của Firebase, thì các lựa chọn nhà cung cấp OAuth 2.0 / OpenID Connect (Google, Facebook, v.v.) là an toàn nhất. Bạn nên hỗ trợ một hoặc nhiều nhà cung cấp này nếu có thể (tuỳ thuộc vào cơ sở người dùng của bạn).

Xác thực bằng email và mật khẩu: đặt hạn mức chặt chẽ cho điểm cuối đăng nhập để ngăn chặn các cuộc tấn công dò mật khẩu

Nếu bạn sử dụng dịch vụ xác thực bằng email và mật khẩu được quản lý của Firebase, hãy thắt chặt hạn mức mặc định của các điểm cuối identitytoolkit.googleapis.com để ngăn chặn các cuộc tấn công dò mật khẩu. Bạn có thể thực hiện việc này trên trang Identity Toolkit API trong bảng điều khiển Google Cloud.

Xác thực bằng email và mật khẩu: Bật tính năng bảo vệ chống liệt kê email

Nếu bạn sử dụng dịch vụ xác thực bằng email và mật khẩu được quản lý của Firebase, hãy bật tính năng bảo vệ chống liệt kê email, Tính năng này giúp ngăn chặn các đối tượng xấu lợi dụng các điểm cuối xác thực của dự án để đoán tên tài khoản.

Nâng cấp lên Google Cloud Identity Platform để xác thực đa yếu tố

Để tăng cường bảo mật khi đăng nhập, bạn có thể thêm tính năng hỗ trợ xác thực đa yếu tố bằng cách nâng cấp lên Google Cloud Identity Platform. Mã Firebase Authentication hiện có của bạn sẽ tiếp tục hoạt động sau khi bạn nâng cấp.

Xác thực ẩn danh

Chỉ sử dụng tính năng xác thực ẩn danh cho quá trình giới thiệu người dùng mới

Chỉ sử dụng tính năng xác thực ẩn danh để lưu trạng thái cơ bản cho người dùng trước khi họ thực sự đăng nhập. Tính năng xác thực ẩn danh không thay thế được cho tính năng đăng nhập của người dùng.

Chuyển đổi người dùng sang một phương thức đăng nhập khác nếu họ muốn có dữ liệu trên các thiết bị khác

Dữ liệu xác thực ẩn danh sẽ không tồn tại nếu người dùng xoá bộ nhớ cục bộ hoặc chuyển đổi thiết bị. Nếu cần duy trì dữ liệu sau khi khởi động lại ứng dụng trên một thiết bị, hãy chuyển đổi người dùng sang một tài khoản vĩnh viễn.

Sử dụng các quy tắc bảo mật yêu cầu người dùng phải chuyển đổi sang nhà cung cấp dịch vụ đăng nhập hoặc đã xác minh email của họ

Bất kỳ ai cũng có thể tạo tài khoản ẩn danh trong dự án của bạn. Hãy nhớ rằng, hãy bảo vệ tất cả dữ liệu không công khai bằng các quy tắc bảo mật yêu cầu các phương thức đăng nhập cụ thể hoặc địa chỉ email đã xác minh.

Ví dụ:

allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;

Tính an toàn của Cloud Functions

Không bao giờ đặt thông tin nhạy cảm vào các biến môi trường

Thông thường, trong một ứng dụng Node.js tự lưu trữ, bạn sử dụng các biến môi trường để chứa thông tin nhạy cảm như khoá riêng tư. Không thực hiện việc này trong Cloud Functions. Vì Cloud Functions sử dụng lại các môi trường giữa các lệnh gọi hàm, nên không được lưu trữ thông tin nhạy cảm trong môi trường.

• Để lưu trữ khoá API Firebase (không phải là bí mật), chỉ cần nhúng các khoá này vào mã.

• Nếu bạn đang sử dụng Firebase Admin SDK trong Cloud Functions, thì bạn không cần cung cấp rõ ràng thông tin đăng nhập tài khoản dịch vụ, vì Admin SDK có thể tự động lấy thông tin đăng nhập này trong quá trình khởi chạy.

• Nếu bạn đang gọi các API của Google và Google Cloud yêu cầu thông tin đăng nhập tài khoản dịch vụ, thì thư viện Google Auth cho Node.js có thể lấy thông tin đăng nhập này từ thông tin đăng nhập mặc định của ứng dụng, thông tin đăng nhập này sẽ tự động được điền trong Cloud Functions.

• Để cung cấp khoá riêng tư và thông tin đăng nhập cho các dịch vụ không phải của Google cho Cloud Functions, hãy sử dụng Secret Manager.

Mã hoá thông tin nhạy cảm

Nếu không thể tránh việc truyền thông tin nhạy cảm cho các hàm, bạn phải đưa ra giải pháp tuỳ chỉnh của riêng mình để mã hoá thông tin.

Các hàm đơn giản an toàn hơn; nếu cần độ phức tạp, hãy cân nhắc sử dụng Cloud Run

Cố gắng giữ cho các hàm của bạn càng cơ bản và dễ hiểu càng tốt. Độ phức tạp trong các hàm thường có thể dẫn đến các lỗi khó phát hiện hoặc hành vi không mong muốn.

Nếu cần logic hoặc cấu hình môi trường phức tạp, hãy cân nhắc sử dụng Cloud Run thay vì Cloud Functions.

Quản lý môi trường

Thiết lập dự án phát triển và dự án thử nghiệm

Thiết lập các dự án Firebase riêng biệt cho quá trình phát triển, thử nghiệm và chính thức. Đừng hợp nhất mã ứng dụng vào bản chính thức cho đến khi mã đó được kiểm thử trên dự án thử nghiệm.

Giới hạn quyền truy cập của nhóm vào dữ liệu chính thức

Nếu làm việc với một nhóm lớn hơn, bạn có thể giảm thiểu hậu quả của các lỗi và vi phạm bằng cách giới hạn quyền truy cập vào dữ liệu chính thức bằng cách sử dụng vai trò IAM được xác định trước hoặc vai trò IAM tuỳ chỉnh.

Nếu nhóm của bạn sử dụng Firebase Local Emulator Suite (nên dùng) để phát triển, thì bạn có thể không cần cấp quyền truy cập rộng hơn vào dự án chính thức.

Quản lý thư viện

Cẩn thận với lỗi chính tả thư viện hoặc người duy trì mới

Khi thêm thư viện vào dự án, hãy chú ý đến tên của thư viện và người duy trì thư viện đó. Một thư viện có tên tương tự với thư viện mà bạn dự định cài đặt có thể chứa mã độc hại.

Đừng cập nhật thư viện mà không hiểu rõ các thay đổi

Xem qua nhật ký thay đổi của bất kỳ thư viện nào mà bạn sử dụng trước khi nâng cấp. Đảm bảo rằng bản nâng cấp mang lại giá trị và kiểm tra xem người duy trì vẫn là bên mà bạn tin tưởng.

Cài đặt thư viện giám sát dưới dạng phần phụ thuộc kiểm thử hoặc phát triển

Sử dụng một thư viện như Snyk để quét dự án của bạn nhằm tìm các phần phụ thuộc không an toàn.

Thiết lập tính năng giám sát cho Cloud Functions; kiểm tra sau khi cập nhật thư viện

Nếu bạn sử dụng Cloud Functions SDK trình ghi nhật ký, thì bạn có thể giám sát và được cảnh báo về hành vi bất thường, bao gồm cả hành vi do bản cập nhật thư viện gây ra.