Để 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 những mục này khi bạn 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 bất hợp pháp, 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ỉ các ứ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 để 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 xảy ra một cuộc tấn công, điều này có thể dẫn đến hoá đơn 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 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ó mức tăng đột biến về yêu cầu, 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à thanh toán.
Thiết lập cảnh báo về ngân sách cho dự án của bạ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ụ áp dụng 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 hoạt động 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 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 bất hợp pháp bằng cách xử lý kết quả theo lô: xuất bản kết quả vào 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ụ của 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 những 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ả các khoá API do Firebase cung cấp đều được tự động giới hạn ở 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ế đối với khoá API để giới hạn phạm vi khoá API cho các ứ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 các 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.
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 sử dụng) rất nhạy cảm và phải được giữ bí mật.
Firebase Security Rules
Khởi tạo 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 động 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 phiên bản mới của Cloud Firestore (chế độ sản xuất) 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 đồ; hãy thêm quy tắc khi bạn thêm tài liệu
Đừng viết các 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 đó.
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 bài kiểm thử này vào quy trình CI. 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 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 (cho dù là hệ thống tuỳ chỉnh hay dịch vụ của bên thứ ba), bạn có thể 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ý: 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 về 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 bằng mật khẩu và email do Firebase quản lý, hãy tăng 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ò tìm 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 mật khẩu và email do Firebase quản lý, hãy bật tính năng bảo vệ chống liệt kê email. Tính năng này ngăn chặn các tác nhân độc hại 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 để 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 vẫn sẽ 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
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ế được quy trình đăng nhập của người dùng.
Chuyển 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 duy trì 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 một tài khoản ẩn danh trong dự án của bạn. Hãy nhớ rằng bạn phải 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 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ẽ 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 phải là khoá bí mật), chỉ cần nhúng khoá đó vào mã.
Nếu đang dùng Firebase Admin SDK trong Cloud Functions, 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 này trong quá trình khởi tạo.
Nếu bạn đang gọi các API Google Cloud của Google và những API 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 đư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 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
Hãy 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à dự án dàn dựng
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 với bản phát hành công khai cho đến khi mã đó được kiểm thử với dự án dàn dựng.
Hạn chế 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 xâm nhập bằng cách giới hạn quyền truy cập vào dữ liệu sản xuất bằng cách sử dụng các vai trò IAM được xác định trước hoặc cá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 cho dự án phát hành công khai.
Quản lý thư viện
Lưu ý 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 dự định cài đặt có thể chứa mã độc.
Đừng cập nhật thư viện nếu chưa hiểu rõ các thay đổi
Xem kỹ 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ị và kiểm tra để chắc chắn rằng người duy trì vẫn là bên mà bạn tin tưởng.
Cài đặt 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 nhằm 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 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.