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

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

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

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

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

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

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

เปิดใช้ App Check

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

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

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

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

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

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

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

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

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

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

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

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

Firebase ใช้คีย์ API เพื่อระบุโปรเจ็กต์ Firebase ของแอปกับบริการ Firebase เท่านั้น และไม่ได้ควบคุมการเข้าถึงฐานข้อมูลหรือข้อมูล Cloud Storage ซึ่งทำได้โดยใช้ Firebase Security Rules คุณจึงไม่จําเป็นต้องถือว่าคีย์ API สําหรับบริการ Firebase เป็นข้อมูลลับ และสามารถฝังคีย์เหล่านั้นในโค้ดไคลเอ็นต์ได้อย่างปลอดภัย ดูข้อมูลเพิ่มเติมเกี่ยวกับคีย์ API สําหรับ Firebase

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

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

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

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

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

นอกจากนี้ คีย์ส่วนตัวของบัญชีบริการ (ใช้โดย 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

การตรวจสอบสิทธิ์ที่มีการจัดการ: ผู้ให้บริการ 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 จะใช้สภาพแวดล้อมซ้ำระหว่างการเรียกใช้ฟังก์ชัน คุณจึงไม่ควรจัดเก็บข้อมูลที่ละเอียดอ่อนไว้ในสภาพแวดล้อม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การจัดการคลัง

ระวังการสะกดคลังที่ไม่ถูกต้องหรือผู้ดูแลรายใหม่

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

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

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

ติดตั้งไลบรารีเครื่องมือตรวจสอบข้อบกพร่องเป็นทรัพยากร Dependency สําหรับนักพัฒนาซอฟต์แวร์หรือการทดสอบ

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

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

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