Để giữ an toàn cho các tài nguyên Firebase và dữ liệu của người dùng, hãy làm theo các nguyên tắc này. 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 ý đến các mục đó khi phát triển ứng dụng.
Tránh lưu lượng truy cập sai trá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 sai trá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 bạn 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 Firebase App Check cho mọi dịch vụ hỗ trợ tính năng này.
Định cấu hình Cloud Functions để điều chỉnh quy mô cho lưu lượng truy cập thông thường
Cloud Functions tự động cấp tài nguyên bổ sung để đá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ể khiến bạn phải trả một khoản phí lớn. Để ngăn chặn điều này, bạn có thể giới hạn số lượng thực thể đồ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 của mình.
Thiết lập cảnh báo để nhận thông báo khi gần đạt đến hạn mức
Nếu dịch vụ của bạn có lượng yêu cầu 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 đến ứng dụng của bạn.
Hãy nhớ theo dõi trang tổng quan Mức sử dụng và thông tin thanh toán.
Thiết lập cảnh báo về ngân sách cho dự án để nhận thông báo khi mức sử dụng tài nguyên vượt quá dự kiến.
Nếu bạn sử dụng Firebase AI Logic, Firebase App Hosting, Cloud Functions for Firebase và Firebase Extensions, hãy thiết lập hạn mức chi tiêu để tạm dừng dịch vụ hiện hành nếu dự án của bạn đạt đến ngân sách đã đặt cho dịch vụ đó.
Ngăn chặn các cuộc tấn công từ chối dịch vụ (DOS) tự gây ra: kiểm thử các hàm cục bộ bằng trình mô phỏng
Bạn có thể vô tình tự DOS trong 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 phát trực tiếp bằng cách phát triển với Firebase Local Emulator Suite.
Và nếu bạn vô tình tự DOS, hãy huỷ triển khai hàm bằng cách xoá hàm đó khỏi index.js rồi 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 thận trọng
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 sai trái bằng cách xử lý kết quả theo lô: xuất bản kết quả lên một chủ đề Pub/Sub và xử lý kết quả theo định kỳ bằng một hàm theo lịch.
Tìm hiểu về khoá API
Khoá API cho các dịch vụ Firebase không phải là khoá 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 cho các dịch vụ đó. Uỷ quyền được xử lý thông qua các quyền IAM Google Cloud, 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 chế độ 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ì bạn không cần coi khoá API bị hạn chế đối với các dịch vụ Firebase 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 nhớ áp dụng các quy tắc hạn chế về khoá API để giới hạn phạm vi khoá API cho ứng dụng khách và API mà bạn sử dụng.
Chỉ sử dụng khoá API do Firebase cung cấp 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ụ: Places API cho Maps hoặc Gemini Developer API), hãy sử dụng khoá API riêng biệt và hạn chế khoá đó đối với API có thể á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 API HTTP FCM cũ sử dụng) là khoá nhạy cảm và phải được giữ bí mật.
Bật tính năng ghi nhật ký kiểm tra cho Cloud Messaging
Hãy cân nhắc việc bật tính năng ghi nhật ký kiểm tra trên đám mây cho Cloud Messaging để bạn có thể ghi lại các hoạt động quản trị và sự kiện truy cập trong các tài nguyên FCM.
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ụ (được Firebase Admin SDK sử dụng) 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ế độ phát hành công khai hoặc chế độ khoá
Khi bạn thiết lập Cloud Firestore, Realtime Database và Cloud Storage, hãy khởi chạy Firebase Security Rules để từ chối tất cả 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 thực thể mới của Cloud Firestore (chế độ phát hành công khai) và Realtime Database (chế độ khoá). Đối với Cloud Storage, hãy bắt đầu bằng 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 giản đồ; 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 nhiệm vụ trước khi ra mắt. Thay vào đó, hãy viết các 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, trước tiên 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 đó.
Kiểm thử đơn vị các quy tắc bảo mật bằng Local Emulator Suite; thêm quy tắc đó vào CI
Để đảm bảo các quy tắc bảo mật của bạn luô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 quy trình kiểm thử này vào quy trình CI của bạn. Hãy xem các hướng dẫn này để biết thông tin về Cloud Firestore và Realtime Database.
Xác thực
Xác thực tuỳ chỉnh: tạo 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, cho dù là hệ thống tuỳ chỉnh hay dịch vụ của bên thứ ba, thì bạn có thể sử dụng hệ thống hiện có để xác thực bằng các dịch vụ của 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 máy khách của bạn. Máy khách này 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 phương thức xác thực tuỳ chỉnh với một nhà cung cấp bên thứ ba, hãy xem bài đăng trên blog Xác thực bằng Firebase thông qua Okta.
Xác thực được quản lý: Các 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 brute force
Nếu bạn sử dụng dịch vụ xác thực mật khẩu email đượ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 brute force. 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 mật khẩu email được quản lý của Firebase, hãy bật tính năng bảo vệ chống liệt kê email để ngăn chặn các đối tượng xấu lợi dụng đ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 để sử dụng tính năng 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 tại 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 phương thức xác thực ẩn danh cho quy trình tham gia khởi động nhanh
Chỉ sử dụng phương thức 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. Xác thực ẩn danh không thay thế cho việc đă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 được lưu giữ nếu người dùng xoá bộ nhớ cục bộ hoặc chuyển đổi thiết bị. Nếu bạn 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 người dùng sang 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 đã chuyển đổi sang một 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 bạn cần 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 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;
Cloud Functions an toàn
Đừng bao giờ đưa thông tin nhạy cảm vào biến môi trường
Thông thường, trong ứ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ư. Đừng làm 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 bạ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 bí mật), chỉ cần nhúng các khoá đó vào mã.
Nếu đang sử dụng Firebase Admin SDK trong Cloud Functions, bạn không cần phải cung cấp thông tin xác thực tài khoản dịch vụ một cách rõ ràng, vì Admin SDK có thể tự động lấy thông tin xác thực trong quá trình khởi chạy.
Nếu bạn đang gọi các API Google Cloud của Google yêu cầu thông tin xác thực tài khoản dịch vụ, thì thư viện Google Auth cho Node.js có thể lấy thông tin xác thực này từ thông tin xác thực mặc định của ứng dụng. Thông tin này sẽ được tự động điền vào 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 đến các hàm, bạn phải tự nghĩ ra giải pháp tuỳ chỉnh để mã hoá thông tin.
Các hàm đơn giản sẽ an toàn hơn; nếu bạn cần hàm 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ơ bản và dễ hiểu nhất có thể. Độ phức tạp trong các hàm của bạn 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 bạn cần có 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à thử nghiệm
Thiết lập các dự án Firebase riêng biệt cho giai đoạn phát triển, thử nghiệm và phát hành công khai. Đừng hợp nhất mã ứng dụng khách vào môi trường phát hành chính thức cho đến khi mã đó được kiểm thử dựa 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 phát hành công khai
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à hành vi vi phạm bằng cách giới hạn quyền truy cập vào dữ liệu sản xuất bằ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 phát hành chính thức.
Quản lý thư viện
Đề phòng lỗi chính tả trong 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ự như thư viện mà bạn định cài đặt có thể chứa mã độc hại.
Đừng cập nhật thư viện nếu chưa hiểu rõ các thay đổi
Xem xét nhật ký thay đổi của mọi thư viện bạn sử dụng trước khi nâng cấp. Hãy đảm bảo rằng bản nâng cấp mang lại giá trị gia tăng và kiểm tra để chắc chắn rằng người bảo trì vẫn là bên mà bạn tin tưởng.
Cài đặt các thư viện watchdog làm phần phụ thuộc phát triển hoặc kiểm thử
Sử dụng một thư viện như Snyk để quét dự án của bạn để tìm các phần phụ thuộc không an toàn.
Thiết lập chế độ giám sát cho Cloud Functions; kiểm tra chế độ này sau khi cập nhật thư viện
Nếu sử dụng SDK trình ghi nhật ký Cloud Functions, thì bạn có thể giám sát và nhận được cảnh báo về hành vi bất thường, kể cả hành vi do các bản cập nhật thư viện gây ra.