เรียนรู้ไวยากรณ์หลักของภาษาของกฎการรักษาความปลอดภัยของ Firebase สำหรับ Cloud Storage

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

หากต้องการความช่วยเหลือจาก AI ให้คัดลอกพรอมต์ด้านล่างลงในตัวแทนการเขียนโค้ด AI (เช่น Gemini ใน Android Studio, Antigravity, Claude Code, Codex และ Cursor) คุณสามารถปรับแต่งพรอมต์และทำซ้ำกับ Agent ได้ ดูข้อมูลการติดตั้งโดยละเอียดได้ที่ทักษะเอเจนต์ Firebase

Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's Cloud Storage data.

คู่มือนี้จะอธิบายไวยากรณ์และโครงสร้างพื้นฐานของ Cloud Storage Security Rules เพื่อสร้างชุดกฎที่สมบูรณ์

การประกาศบริการและฐานข้อมูล

Firebase Security Rules สำหรับ Cloud Storage จะขึ้นต้นด้วยการประกาศต่อไปนี้เสมอ

service firebase.storage {
    // ...
}

การประกาศ service firebase.storage จะกำหนดขอบเขตของกฎเป็น Cloud Storage เพื่อป้องกันความขัดแย้งระหว่าง Cloud Storage Security Rules กับกฎสำหรับผลิตภัณฑ์อื่นๆ เช่น Cloud Firestore

กฎการอ่าน/เขียนพื้นฐาน

กฎพื้นฐานประกอบด้วยคำสั่ง match ที่ระบุที่เก็บข้อมูล Cloud Storage, คำสั่งจับคู่ที่ระบุชื่อไฟล์ และนิพจน์ allow ที่ให้รายละเอียดว่าเมื่อใดที่อนุญาตให้อ่านข้อมูลที่ระบุได้ นิพจน์ allow จะระบุวิธีการเข้าถึง (เช่น อ่าน เขียน) ที่เกี่ยวข้อง และเงื่อนไขที่อนุญาตหรือปฏิเสธการเข้าถึง

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

service firebase.storage {
  // The {bucket} wildcard indicates we match files in all Cloud Storage buckets
  match /b/{bucket}/o {
    // Match filename
    match /filename {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

คำสั่ง match ทั้งหมดจะชี้ไปยังไฟล์ คำสั่งจับคู่สามารถชี้ไปยังไฟล์ที่เฉพาะเจาะจงได้ เช่น match /images/profilePhoto.png

จับคู่สัญลักษณ์แทน

นอกจากจะชี้ไปยังไฟล์เดียวแล้ว Security Rules ยังใช้ไวลด์การ์ดเพื่อชี้ไปยังไฟล์ที่มีคำนำหน้าสตริงที่ระบุในชื่อได้ด้วย รวมถึงเครื่องหมายทับ เช่น match /images/{imageId}

ในตัวอย่างข้างต้น คำสั่งจับคู่จะใช้ไวยากรณ์ไวลด์การ์ด {imageId} ซึ่งหมายความว่ากฎจะมีผลกับไฟล์ที่มี /images/ อยู่ที่จุดเริ่มต้นของชื่อ เช่น /images/profilePhoto.png หรือ /images/croppedProfilePhoto.png เมื่อประเมินนิพจน์ allow ในคำสั่งจับคู่ ตัวแปร imageId จะเปลี่ยนเป็นชื่อไฟล์รูปภาพ เช่น profilePhoto.png หรือ croppedProfilePhoto.png

คุณสามารถอ้างอิงตัวแปรไวลด์การ์ดจากภายใน match เพื่อให้สิทธิ์ชื่อไฟล์หรือเส้นทางได้ ดังนี้

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

ข้อมูลแบบลำดับชั้น

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

พิจารณาสถานการณ์ของชุดไฟล์ที่มีชื่อซึ่งขึ้นต้นด้วย /images/ ทั้งหมด Firebase Security Rules จะมีผลเฉพาะกับชื่อไฟล์ที่ตรงกันเท่านั้น ดังนั้นการควบคุมการเข้าถึงที่กำหนดไว้ในต้นกำเนิด /images/ จะไม่มีผลกับต้นกำเนิด /mp3s/ แต่ให้เขียนกฎที่ชัดเจนซึ่งตรงกับรูปแบบชื่อไฟล์ต่างๆ แทน ดังนี้

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      allow read, write: if <condition>;
    }

    // Explicitly define rules for the 'mp3s' pattern
    match /mp3s/{mp3Id} {
      allow read, write: if <condition>;
    }
  }
}

เมื่อซ้อนคำสั่ง match เส้นทางของคำสั่ง match ด้านในจะต่อท้ายเส้นทางของคำสั่ง match ด้านนอกเสมอ ดังนั้นชุดกฎ 2 ชุดต่อไปนี้จึงเทียบเท่ากัน

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Exact match for "images/profilePhoto.png"
      match /profilePhoto.png {
        allow write: if <condition>;
      }
    }
  }
}
service firebase.storage {
  match /b/{bucket}/o {
    // Exact match for "images/profilePhoto.png"
    match /images/profilePhoto.png {
      allow write: if <condition>;
      }
  }
}

ไวลด์การ์ดการจับคู่แบบเกิดซ้ำ

นอกเหนือจากไวลด์การ์ดที่จับคู่และแสดงผลสตริงที่ส่วนท้ายของชื่อไฟล์แล้ว คุณยังประกาศไวลด์การ์ดหลายกลุ่มเพื่อการจับคู่ที่ซับซ้อนยิ่งขึ้นได้โดยเพิ่ม =** ลงในชื่อไวลด์การ์ด เช่น {path=**}

// Partial match for files that start with "images"
match /images {

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

หากกฎหลายข้อตรงกับไฟล์ ผลลัพธ์จะเป็น OR ของผลลัพธ์ของการประเมินกฎทั้งหมด กล่าวคือ หากกฎที่ไฟล์ตรงกันประเมินเป็น true ผลลัพธ์จะเป็น true

ในกฎข้างต้น ไฟล์ "images/profilePhoto.png" จะอ่านได้หาก condition หรือ other_condition ประเมินเป็นจริง ส่วนไฟล์ "images/users/user:12345/profilePhoto.png" จะขึ้นอยู่กับผลลัพธ์ของ other_condition เท่านั้น

Cloud Storage Security Rules จะไม่ทำงานแบบเรียงซ้อน และระบบจะประเมินกฎก็ต่อเมื่อเส้นทางคำขอตรงกับเส้นทางที่มีการระบุกฎไว้เท่านั้น

เวอร์ชัน 1

Firebase Security Rules ใช้เวอร์ชัน 1 โดยค่าเริ่มต้น ในเวอร์ชัน 1 ไวลด์การ์ดแบบเรียกซ้ำจะจับคู่กับองค์ประกอบชื่อไฟล์อย่างน้อย 1 รายการ ไม่ใช่องค์ประกอบตั้งแต่ 0 รายการขึ้นไป ดังนั้น match /images/{filenamePrefixWildcard}/{imageFilename=**} จะตรงกับชื่อไฟล์ เช่น /images/profilePics/profile.png แต่ไม่ตรงกับ /images/badge.png โปรดใช้ /images/{imagePrefixorFilename=**} แทน

ไวลด์การ์ดแบบเรียกซ้ำต้องอยู่ท้ายคำสั่งการจับคู่

เราขอแนะนำให้คุณใช้เวอร์ชัน 2 เนื่องจากมีฟีเจอร์ที่มีประสิทธิภาพมากกว่า

เวอร์ชัน 2

ในเวอร์ชัน 2 ของ Firebase Security Rules ไวลด์การ์ดแบบเรียกซ้ำจะจับคู่กับรายการเส้นทาง 0 รายการขึ้นไป ดังนั้น /images/{filenamePrefixWildcard}/{imageFilename=**} จะตรงกับชื่อไฟล์ /images/profilePics/profile.png และ /images/badge.png

คุณต้องเลือกใช้เวอร์ชัน 2 โดยเพิ่ม rules_version = '2'; ที่ด้านบนของกฎความปลอดภัย ดังนี้

rules_version = '2';
service cloud.storage {
  match /b/{bucket}/o {
   ...
 }
}

คุณมีไวลด์การ์ดแบบเรียกซ้ำได้สูงสุด 1 รายการต่อคำสั่งการจับคู่ แต่ในเวอร์ชัน 2 คุณสามารถวางไวลด์การ์ดนี้ไว้ที่ใดก็ได้ในคำสั่งการจับคู่ เช่น

rules_version = '2';
service firebase.storage {
 match /b/{bucket}/o {
   // Matches any file in a songs "subdirectory" under the
   // top level of your Cloud Storage bucket.
   match /{prefixSegment=**}/songs/{mp3filenames} {
     allow read, write: if <condition>;
   }
  }
}

การดำเนินการแบบละเอียด

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

การดำเนินการ read แบ่งออกเป็น get และ list ได้

กฎ write สามารถแบ่งออกเป็น create, update และ delete ได้ดังนี้

service firebase.storage {
  match /b/{bucket}/o {
    // A read rule can be divided into read and list rules
    match /images/{imageId} {
      // Applies to single file read requests
      allow get: if <condition>;
      // Applies to list and listAll requests (Security Rules Version 2)
      allow list: if <condition>;

    // A write rule can be divided into create, update, and delete rules
    match /images/{imageId} {
      // Applies to writes to file contents
      allow create: if <condition>;

      // Applies to updates to (pre-existing) file metadata
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
 }
}

คำสั่งการจับคู่ที่ทับซ้อนกัน

ชื่อไฟล์อาจตรงกับคำสั่ง match มากกว่า 1 รายการ ในกรณีที่นิพจน์ allow หลายรายการตรงกับคำขอ ระบบจะอนุญาตให้เข้าถึงได้หากเงื่อนไขใดก็ตามเป็น true:

service firebase.storage {
  match b/{bucket}/o {
    // Matches file names directly inside of '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches file names anywhere under `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

ในตัวอย่างข้างต้น ระบบจะอนุญาตให้อ่านและเขียนไฟล์ทั้งหมดที่มีชื่อขึ้นต้นด้วย /images/ เนื่องจากกฎข้อที่ 2 เป็น true เสมอ แม้ว่ากฎข้อแรกจะเป็น false ก็ตาม

กฎไม่ใช่ตัวกรอง

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

ตัวอย่างเช่น ลองดูกฎความปลอดภัยต่อไปนี้

service firebase.storage {
  match /b/{bucket}/o {
    // Allow the client to read files with contentType 'image/png'
    match /aFileNamePrefix/{aFileName} {
      allow read: if resource.contentType == 'image/png';
    }
  }
}

ปฏิเสธ: กฎนี้ปฏิเสธคำขอต่อไปนี้เนื่องจากชุดผลลัพธ์อาจรวมไฟล์ที่ contentType ไม่ใช่ image/png:

เว็บ
filesRef = storage.ref().child("aFilenamePrefix");

filesRef.listAll()
    .then(function(result) {
      console.log("Success: ", result.items);
    })
});

กฎใน Cloud Storage Security Rules จะประเมินการค้นหาแต่ละรายการเทียบกับผลลัพธ์ที่เป็นไปได้ และจะทำให้คำขอล้มเหลวหากอาจแสดงผลไฟล์ที่ไคลเอ็นต์ไม่มีสิทธิ์อ่าน คำขอเข้าถึงต้องเป็นไปตามข้อจำกัดที่กฎของคุณกำหนดไว้

ขั้นตอนถัดไป

คุณสามารถทำความเข้าใจ Firebase Security Rules สำหรับ Cloud Storage ให้ลึกซึ้งยิ่งขึ้นได้ดังนี้

  • เรียนรู้แนวคิดหลักถัดไปของภาษา Rules ซึ่งก็คือเงื่อนไขแบบไดนามิก ซึ่งช่วยให้กฎตรวจสอบการให้สิทธิ์ผู้ใช้ เปรียบเทียบข้อมูลที่มีอยู่กับข้อมูลขาเข้า ตรวจสอบข้อมูลขาเข้า และอื่นๆ

  • ตรวจสอบกรณีการใช้งานด้านความปลอดภัยทั่วไปและคำจำกัดความของ Firebase Security Rules ที่เกี่ยวข้อง

คุณสามารถสำรวจกรณีการใช้งาน Firebase Security Rules ที่เจาะจงสำหรับ Cloud Storage ได้ดังนี้