รายการตรวจสอบความปลอดภัยของ Firebase

ทำตามหลักเกณฑ์เหล่านี้เพื่อรักษาความปลอดภัยของทรัพยากร Firebase และข้อมูลของผู้ใช้ ไม่ใช่ทุกรายการที่จะเกี่ยวข้องกับข้อกำหนดของคุณ แต่โปรดคำนึงถึงรายการเหล่านี้ขณะพัฒนาแอป

หลีกเลี่ยงการเข้าชมที่เป็นการละเมิด

ตั้งค่าการตรวจสอบและการแจ้งเตือนสำหรับบริการแบ็กเอนด์

หากต้องการตรวจหาการเข้าชมที่เป็นการละเมิด เช่น การโจมตีแบบปฏิเสธการให้บริการ (DOS) ให้ตั้งค่า การตรวจสอบและการแจ้งเตือนสำหรับ Cloud Firestore, Realtime Database, Cloud Storage และ Hosting

หากสงสัยว่าแอปพลิเคชันของคุณถูกโจมตี โปรดติดต่อทีมสนับสนุนโดยเร็วที่สุดเพื่อ แจ้งให้ทราบถึงสิ่งที่เกิดขึ้น

เปิดใช้ App Check

หากต้องการช่วยให้มั่นใจว่ามีเพียงแอปของคุณเท่านั้นที่เข้าถึงบริการแบ็กเอนด์ได้ ให้เปิดใช้ Firebase App Check สำหรับทุกบริการที่รองรับ

กำหนดค่า Cloud Functions ให้ปรับขนาดตามการเข้าชมปกติ

Cloud Functions จะปรับขนาดโดยอัตโนมัติเพื่อตอบสนองความต้องการของแอป แต่ใน กรณีที่เกิดการโจมตี การดำเนินการนี้อาจทำให้ค่าบริการสูงขึ้นมาก คุณสามารถ จำกัดจำนวนอินสแตนซ์พร้อมกัน ของฟังก์ชันตามการเข้าชมปกติของแอปเพื่อป้องกันไม่ให้เกิดเหตุการณ์ดังกล่าว

ตั้งค่าการแจ้งเตือนให้คุณได้รับแจ้งเมื่อใกล้ถึงขีดจำกัด

หากบริการของคุณมีการเพิ่มขึ้นอย่างรวดเร็วของคำขอ ระบบมักจะเริ่มใช้โควต้าและจำกัดการเข้าชมแอปพลิเคชันของคุณโดยอัตโนมัติ

• ตรวจสอบแดชบอร์ด การใช้งานและการเรียกเก็บเงิน

• ตั้งค่าการแจ้งเตือนเรื่องงบประมาณ สำหรับโปรเจ็กต์เพื่อให้คุณได้รับแจ้งเมื่อการใช้ทรัพยากรเกินความคาดหมาย

• หากคุณใช้ Firebase AI Logic, Firebase App Hosting, Cloud Functions for Firebase, และ Firebase Extensions ให้ตั้งค่า ขีดจำกัดการใช้จ่ายเพื่อหยุดบริการที่เกี่ยวข้องชั่วคราวหากโปรเจ็กต์ใช้จ่ายถึงงบประมาณที่ตั้งไว้สำหรับบริการนั้น

ป้องกันการโจมตี DOS ด้วยตนเอง: ทดสอบฟังก์ชันในเครื่องด้วยโปรแกรมจำลอง

คุณอาจโจมตี DOS ตัวเองโดยไม่ตั้งใจขณะพัฒนา Cloud Functions ได้ง่ายๆ เช่น การสร้างลูปการเขียนทริกเกอร์แบบไม่สิ้นสุด คุณสามารถป้องกันไม่ให้ข้อผิดพลาดเหล่านี้ส่งผลต่อบริการที่ใช้งานจริงได้โดยทำการ พัฒนาด้วย Firebase Local Emulator Suite.

และหากคุณโจมตี DOS ตัวเองโดยไม่ตั้งใจ ให้ยกเลิกการติดตั้งใช้งานฟังก์ชันโดยลบฟังก์ชันออกจาก index.js แล้วเรียกใช้ firebase deploy --only functions

จัดโครงสร้างฟังก์ชันอย่างระมัดระวังในกรณีที่การตอบสนองแบบเรียลไทม์มีความสำคัญน้อยกว่า

หากไม่จำเป็นต้องแสดงผลลัพธ์ของฟังก์ชันแบบเรียลไทม์ คุณสามารถ ลดการเข้าชมที่เป็นการละเมิดได้โดยการประมวลผลผลลัพธ์เป็นชุดๆ กล่าวคือ เผยแพร่ ผลลัพธ์ไปยัง Pub/Sub หัวข้อ และประมวลผลผลลัพธ์เป็นระยะๆ ด้วย ฟังก์ชันที่กำหนดเวลาไว้

ทำความเข้าใจคีย์ API

คีย์ API สำหรับบริการ Firebase ไม่ใช่ข้อมูลลับ

คีย์ API สำหรับบริการ Firebase จะทำหน้าที่เพียง ระบุ โปรเจ็กต์และแอป Firebase ของคุณให้บริการเหล่านั้นทราบ ระบบจะจัดการ Google Cloud สิทธิ์ IAM Firebase Security Rules และ Firebase App Check

คีย์ API ทั้งหมดที่ Firebase จัดสรรให้จะถูกจำกัดให้ใช้ได้กับ API ที่เกี่ยวข้องกับ Firebase โดยอัตโนมัติ หากการตั้งค่าแอปเป็นไปตามหลักเกณฑ์ในหน้านี้ คุณก็ ไม่ จำเป็นต้องถือว่า คีย์ API ที่จำกัดให้ใช้ได้กับบริการ Firebase เป็นข้อมูลลับ และสามารถใส่คีย์ API เหล่านี้ไว้ในโค้ดหรือไฟล์การกำหนดค่าได้อย่างปลอดภัย

ตั้งค่าข้อจำกัดของคีย์ API

หากคุณใช้คีย์ API สำหรับบริการอื่นๆ ของ Google โปรดตรวจสอบว่าได้ใช้ ข้อจำกัดของคีย์ API เพื่อกำหนดขอบเขตคีย์ API ให้กับไคลเอ็นต์แอปและ API ที่คุณใช้

ใช้คีย์ API ที่ Firebase จัดสรรให้ เท่านั้น สำหรับ API ที่เกี่ยวข้องกับ Firebase หากแอปใช้ API อื่นๆ (เช่น Places API สำหรับ Maps หรือ Gemini Developer API) ให้ใช้ คีย์ API แยกต่างหาก และจำกัดให้ใช้ได้กับ API ที่เกี่ยวข้อง

เก็บรักษาคีย์เซิร์ฟเวอร์ FCM ไว้เป็นความลับ

คีย์เซิร์ฟเวอร์ FCM (ที่ใช้โดย FCM HTTP API แบบเดิม) เป็น ข้อมูลที่ละเอียดอ่อนและต้องเก็บรักษาไว้เป็นความลับ ซึ่งแตกต่างจากคีย์ API สำหรับบริการ Firebase

เปิดใช้การบันทึกการตรวจสอบสำหรับ Cloud Messaging

พิจารณาเปิดใช้ การตรวจสอบระบบคลาวด์ การบันทึกสำหรับ Cloud Messaging เพื่อ ให้คุณบันทึกกิจกรรมของผู้ดูแลระบบและเหตุการณ์การเข้าถึงภายในทรัพยากร FCM ได้

เก็บรักษาคีย์บัญชีบริการไว้เป็นความลับ

คีย์ส่วนตัวของบัญชีบริการ (ที่ใช้โดย Firebase Admin SDK) เป็น ข้อมูลที่ละเอียดอ่อนและต้อง เก็บรักษาไว้เป็นความลับ ซึ่งแตกต่างจากคีย์ API สำหรับบริการ Firebase

Firebase Security Rules

เริ่มต้นกฎในโหมดที่ใช้งานจริงหรือโหมดล็อก

เมื่อตั้งค่า Cloud Firestore, Realtime Database และ Cloud Storage ให้เริ่มต้น Firebase Security Rulesเพื่อปฏิเสธการเข้าถึงทั้งหมดโดยค่าเริ่มต้น และเพิ่มกฎที่ให้สิทธิ์ เข้าถึงทรัพยากรที่เฉพาะเจาะจงขณะพัฒนาแอป

ใช้การตั้งค่าเริ่มต้นอย่างใดอย่างหนึ่งสำหรับอินสแตนซ์ใหม่ของ Cloud Firestore (โหมดที่ใช้งานจริง ) และ Realtime Database (โหมดล็อก) สำหรับ Cloud Storage ให้เริ่มต้นด้วยการกำหนดค่ากฎความปลอดภัย ดังต่อไปนี้

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

กฎความปลอดภัยเป็นสคีมา ให้เพิ่มกฎเมื่อเพิ่มเอกสาร

อย่าเขียนกฎความปลอดภัยหลังจากเขียนแอปเสร็จแล้ว โดยถือว่าเป็นการดำเนินการก่อนการเปิดตัว แต่ให้เขียนกฎความปลอดภัยไปพร้อมๆ กับการเขียนแอป โดยถือว่ากฎความปลอดภัยเป็นสคีมาของฐานข้อมูล กล่าวคือ เมื่อใดก็ตามที่คุณต้องใช้เอกสารประเภทใหม่หรือโครงสร้างเส้นทางใหม่ ให้เขียนกฎความปลอดภัยของเอกสารหรือเส้นทางนั้นก่อน

ทดสอบกฎความปลอดภัยแบบหน่วยด้วย Local Emulator Suite และเพิ่มกฎความปลอดภัยลงใน CI

ทดสอบกฎความปลอดภัยแบบหน่วยด้วย Firebase Local Emulator Suite และเพิ่มการทดสอบเหล่านี้ลงในไปป์ไลน์ CI เพื่อให้มั่นใจว่ากฎความปลอดภัยเป็นไปตามการพัฒนาแอป ดูคำแนะนำสำหรับ Cloud Firestore และ Realtime Database

การตรวจสอบสิทธิ์

การตรวจสอบสิทธิ์ที่กำหนดเอง: สร้าง JWT จากสภาพแวดล้อมที่เชื่อถือได้ (ฝั่งเซิร์ฟเวอร์)

หากคุณมีระบบการลงชื่อเข้าใช้ที่ปลอดภัยอยู่แล้ว ไม่ว่าจะเป็นระบบที่กำหนดเองหรือบริการของบุคคลที่สาม คุณก็สามารถใช้ระบบที่มีอยู่เพื่อตรวจสอบสิทธิ์กับบริการ Firebase ได้ สร้าง JWT ที่กำหนดเอง จากสภาพแวดล้อมที่เชื่อถือได้ จากนั้นส่งโทเค็นไปยังไคลเอ็นต์ ซึ่งจะใช้ โทเค็นเพื่อตรวจสอบสิทธิ์ (iOS+, Android, เว็บ, Unity, C++)

ดูตัวอย่างการใช้การตรวจสอบสิทธิ์ที่กำหนดเองกับผู้ให้บริการบุคคลที่สามได้ที่ บล็อกโพสต์ ตรวจสอบสิทธิ์กับ Firebase โดยใช้ Okta

การตรวจสอบสิทธิ์ที่จัดการโดย Firebase: ผู้ให้บริการ OAuth 2.0 มีความปลอดภัยมากที่สุด

หากคุณใช้ฟีเจอร์การตรวจสอบสิทธิ์ที่จัดการโดย Firebase ตัวเลือกผู้ให้บริการ OAuth 2.0 / OpenID Connect (Google, Facebook ฯลฯ) จะมีความปลอดภัยมากที่สุด คุณควรสนับสนุนผู้ให้บริการเหล่านี้อย่างน้อย 1 รายการหากทำได้ (ขึ้นอยู่กับฐานผู้ใช้)

การตรวจสอบสิทธิ์ด้วยอีเมลและรหัสผ่าน: ตั้งค่าโควต้าที่เข้มงวดสำหรับปลายทางของการลงชื่อเข้าใช้เพื่อป้องกันการโจมตีแบบบรูตฟอร์ซ

หากคุณใช้บริการการตรวจสอบสิทธิ์ด้วยอีเมลและรหัสผ่านที่จัดการโดย Firebase ให้เพิ่มความเข้มงวดของโควต้าเริ่มต้นของปลายทาง identitytoolkit.googleapis.com เพื่อป้องกันการโจมตีแบบ Brute Force คุณสามารถทำได้จากหน้า Identity Toolkit API ในคอนโซล Google Cloud

การตรวจสอบสิทธิ์ด้วยอีเมลและรหัสผ่าน: เปิดใช้การป้องกันการแจกแจงอีเมล

หากคุณใช้บริการการตรวจสอบสิทธิ์ด้วยอีเมลและรหัสผ่านที่จัดการโดย Firebase ให้เปิดใช้การป้องกันการแจกแจงอีเมล ซึ่งจะป้องกันไม่ให้ผู้ไม่ประสงค์ดีใช้ปลายทางการตรวจสอบสิทธิ์ของโปรเจ็กต์ในทางที่ผิดเพื่อ เดาชื่อบัญชี

อัปเกรดเป็น Google Cloud Identity Platform เพื่อใช้การตรวจสอบสิทธิ์แบบหลายปัจจัย

คุณสามารถเพิ่มการรองรับการตรวจสอบสิทธิ์แบบหลายปัจจัยได้โดยอัปเกรดเป็น Google Cloud Identity Platform เพื่อเพิ่มความปลอดภัยในการลงชื่อเข้าใช้ โค้ด Firebase Authentication ที่มีอยู่จะยังคงทำงานได้หลังจากที่คุณอัปเกรด

การตรวจสอบสิทธิ์แบบไม่ระบุตัวตน

ใช้การตรวจสอบสิทธิ์แบบไม่ระบุตัวตนสำหรับการเตรียมความพร้อมผู้ใช้งานใหม่แบบอุ่นเท่านั้น

ใช้การตรวจสอบสิทธิ์แบบไม่ระบุตัวตนเพื่อบันทึกสถานะพื้นฐานของผู้ใช้ก่อนที่ผู้ใช้จะลงชื่อเข้าใช้จริงเท่านั้น การตรวจสอบสิทธิ์แบบไม่ระบุตัวตนไม่ใช่การแทนที่การลงชื่อเข้าใช้ของผู้ใช้

เปลี่ยนผู้ใช้เป็นวิธีการลงชื่อเข้าใช้อื่นหากผู้ใช้ต้องการใช้ข้อมูลในอุปกรณ์เครื่องอื่น

ข้อมูลการตรวจสอบสิทธิ์แบบไม่ระบุตัวตนจะ ไม่ คงอยู่หากผู้ใช้ล้างพื้นที่เก็บข้อมูลในเครื่องหรือเปลี่ยนอุปกรณ์ หากต้องการให้ข้อมูลคงอยู่ต่อไปหลังจากรีสตาร์ทแอปใน อุปกรณ์เครื่องเดียว ให้เปลี่ยนผู้ใช้เป็นบัญชีถาวร

ใช้กฎความปลอดภัยที่กำหนดให้ผู้ใช้ต้องเปลี่ยนเป็นผู้ให้บริการลงชื่อเข้าใช้หรือยืนยันอีเมล

ทุกคนสามารถสร้างบัญชีแบบไม่ระบุตัวตนในโปรเจ็กต์ของคุณได้ ดังนั้น ให้ปกป้องข้อมูลที่ไม่ใช่ข้อมูลสาธารณะทั้งหมดด้วย กฎความปลอดภัยที่กำหนดให้ใช้วิธีการลงชื่อเข้าใช้ที่เฉพาะเจาะจงหรือใช้อีเมลยืนยันแล้ว

ตัวอย่างเช่น

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

ความปลอดภัยของ Cloud Functions

อย่าใส่ข้อมูลที่ละเอียดอ่อนในตัวแปรสภาพแวดล้อม

ในแอป Node.js ที่โฮสต์ด้วยตนเอง คุณมักจะใช้ตัวแปรสภาพแวดล้อมเพื่อเก็บข้อมูลที่ละเอียดอ่อน เช่น คีย์ส่วนตัว อย่าทำเช่นนี้ใน Cloud Functions เนื่องจาก Cloud Functions จะใช้ สภาพแวดล้อมซ้ำระหว่างการเรียกใช้ฟังก์ชัน ข้อมูลที่ละเอียดอ่อนจึงไม่ควร จัดเก็บไว้ในสภาพแวดล้อม

• หากต้องการจัดเก็บคีย์ API ของ Firebase (ซึ่ง ไม่ใช่ ข้อมูลลับ) ให้ฝังคีย์ API ไว้ในโค้ด

• หากคุณใช้ Firebase Admin SDK ใน Cloud Functions คุณไม่จำเป็นต้องระบุข้อมูลเข้าสู่ระบบของบัญชีบริการอย่างชัดแจ้ง เนื่องจาก Admin SDK สามารถรับข้อมูลเข้าสู่ระบบเหล่านี้ได้โดยอัตโนมัติระหว่างการเริ่มต้น

• หากคุณเรียกใช้ Google และ Google Cloud API ที่ต้องใช้ข้อมูลเข้าสู่ระบบบัญชีบริการ ไลบรารีการตรวจสอบสิทธิ์ของ Google สำหรับ Node.js จะรับข้อมูลเข้าสู่ระบบเหล่านี้จากข้อมูลเข้าสู่ระบบเริ่มต้นของแอปพลิเคชัน ซึ่งจะมีการป้อนข้อมูลโดยอัตโนมัติใน Cloud Functions

• หากต้องการให้คีย์ส่วนตัวและข้อมูลเข้าสู่ระบบสำหรับบริการที่ไม่ใช่ของ Google พร้อมใช้งานใน Cloud Functions ให้ใช้ Secret Manager

เข้ารหัสข้อมูลที่ละเอียดอ่อน

หากหลีกเลี่ยงการส่งข้อมูลที่ละเอียดอ่อนไปยังฟังก์ชันไม่ได้ คุณต้องสร้างโซลูชันที่กำหนดเองเพื่อเข้ารหัสข้อมูล

ฟังก์ชันที่เรียบง่ายจะปลอดภัยกว่า หากต้องการฟังก์ชันที่ซับซ้อน ให้พิจารณาใช้ Cloud Run

พยายามทำให้ฟังก์ชันมีความเรียบง่ายและเข้าใจง่ายที่สุด ความซับซ้อนในฟังก์ชันอาจทำให้เกิดข้อบกพร่องที่ตรวจพบได้ยากหรือลักษณะการทำงานที่ไม่คาดคิด

หากต้องการตรรกะหรือการกำหนดค่าสภาพแวดล้อมที่ซับซ้อน ให้พิจารณาใช้ Cloud Run แทน Cloud Functions

การจัดการสภาพแวดล้อม

ตั้งค่าโปรเจ็กต์การพัฒนาและการทดสอบ

ตั้งค่าโปรเจ็กต์ Firebase แยกต่างหากสำหรับการพัฒนา การทดสอบ และการใช้งานจริง อย่าผสานโค้ดไคลเอ็นต์เข้ากับการใช้งานจริงจนกว่าจะมีการทดสอบกับโปรเจ็กต์การทดสอบแล้ว

จำกัดการเข้าถึงข้อมูลการใช้งานจริงของทีม

หากคุณทำงานร่วมกับทีมขนาดใหญ่ คุณสามารถลดผลกระทบจากข้อผิดพลาด และการละเมิดได้โดยจำกัดการเข้าถึงข้อมูลการใช้งานจริงโดยใช้ บทบาท IAM ที่กำหนดไว้ล่วงหน้า หรือ บทบาท IAM ที่กำหนดเอง

หากทีมของคุณใช้ Firebase Local Emulator Suite (แนะนำ) สำหรับการพัฒนา คุณอาจไม่จำเป็นต้องให้สิทธิ์เข้าถึง โปรเจ็กต์การใช้งานจริงในวงกว้าง

การจัดการไลบรารี

ระวังการสะกดชื่อไลบรารีผิดหรือผู้ดูแลใหม่

เมื่อเพิ่มไลบรารีลงในโปรเจ็กต์ ให้ใส่ใจกับชื่อของไลบรารีและผู้ดูแล ไลบรารีที่มีชื่อคล้ายกับไลบรารีที่คุณต้องการติดตั้งอาจมีโค้ดที่เป็นอันตราย

อย่าอัปเดตไลบรารีโดยไม่เข้าใจการเปลี่ยนแปลง

อ่านบันทึกการเปลี่ยนแปลงของไลบรารีที่คุณใช้ก่อนที่จะอัปเกรด ตรวจสอบว่าการอัปเกรดมีประโยชน์ และตรวจสอบว่าผู้ดูแลยังคงเป็นบุคคลที่คุณเชื่อถือ

ติดตั้งไลบรารี Watchdog เป็นทรัพยากร Dependency สำหรับการพัฒนาหรือการทดสอบ

ใช้ไลบรารี เช่น Snyk เพื่อสแกนหาทรัพยากร Dependency ที่ไม่ปลอดภัยในโปรเจ็กต์

ตั้งค่าการตรวจสอบสำหรับ Cloud Functions และตรวจสอบหลังจากการอัปเดตไลบรารี

หากคุณใช้ Cloud Functions Logger SDK คุณจะ ตรวจสอบและได้รับการแจ้งเตือน เกี่ยวกับลักษณะการทำงานที่ผิดปกติ ซึ่งรวมถึงลักษณะการทำงานที่เกิดจากการอัปเดตไลบรารี