技能 firestore-rules-creation
📦
firestore-rules-creation
內容修訂 r1 高風險 ⚙️ 外部命令🌐 網路存取
Create Secure Firestore Rules
Firestore Rules can expose private data when access and validation logic are incomplete. This skill helps create structured rules with least-privilege access, schema checks, and security test scenarios.
支援: Claude Codex Code(CC)
安裝前請停止並請求確認。
請審查安裝計畫，並在變更檔案前取得使用者明確同意。
使用我的智慧代理安裝
將此請求複製給你的智慧代理，其中包含權威 Skill 頁面和清單。
智能體請求
Review the Skillstore skill "firestore-rules-creation" from https://skillstore.io/skills/firebase-firestore-rules-creation.md and its manifest at https://skillstore.io/api/skills/firebase-firestore-rules-creation/manifest. Verify the artifact. Stop and obtain explicit user consent before installing or changing files.你的智慧代理仍應顯示其計畫，並依安全政策請求必要確認。
Agent 可讀資源
當 AI Agent、爬蟲或腳本需要乾淨脈絡、而不是讀取完整頁面時，請使用這些連結。
測試它
正在使用「firestore-rules-creation」。 Create rules for private user profiles and public posts.
預期結果:
- Assumed data model for profiles and posts.
- Rules that limit profile access to the owner.
- Rules that allow public post reads without exposing profile PII.
- A list of assumptions and tests to run.
正在使用「firestore-rules-creation」。 Secure a likes counter on each post.
預期結果:
- A counter-update policy that limits changed fields.
- A consistency check for one like per user.
- A replay and batch-operation test checklist.
安全審計
高風險v1 • 2026/9/11 開啟版本化報告
Static detections are false positives caused by Markdown code formatting, Firestore Rules interpolation syntax, and security-focused prose. No command execution, network access, reconnaissance, or credential exposure is present. One semantic issue remains: the guidance to prefer `read` can unintentionally grant both get and list access.
1
已掃描檔案
585
分析行數
0
複核項目
0
已忽略的誤報
已確認的安全問題 (1)
高
Overbroad Read Permission Guidance
The instruction to prefer `read` over `list` or `get` can overgrant access because Firestore `read` covers both single-document reads and queries. Rules should distinguish `get` and `list` when their authorization requirements differ.
The guidance explicitly prefers the broader Firestore read operation without limiting it to cases where get and list have identical authorization requirements.
風險因素
⚙️ 外部命令 (50)
SKILL.md:32 SKILL.md:33 SKILL.md:59 SKILL.md:60 SKILL.md:79-96 SKILL.md:96-100 SKILL.md:100-225 SKILL.md:225-266 SKILL.md:266-273 SKILL.md:273-277 SKILL.md:277-284 SKILL.md:284-288 SKILL.md:288 SKILL.md:289-293 SKILL.md:293-296 SKILL.md:296-299 SKILL.md:299-300 SKILL.md:300-302 SKILL.md:302 SKILL.md:303-304 SKILL.md:304-307 SKILL.md:307 SKILL.md:312 SKILL.md:315-320 SKILL.md:320-334 SKILL.md:334-337 SKILL.md:337-338 SKILL.md:338-343 SKILL.md:343-346 SKILL.md:346-349 SKILL.md:349-352 SKILL.md:352-355 SKILL.md:355-356 SKILL.md:356 SKILL.md:357 SKILL.md:358-375 SKILL.md:375-383 SKILL.md:383-387 SKILL.md:387-393 SKILL.md:393-404 SKILL.md:404-414 SKILL.md:414-417 SKILL.md:417-421 SKILL.md:421 SKILL.md:424 SKILL.md:429-430 SKILL.md:430-435 SKILL.md:435-455 SKILL.md:455-468 SKILL.md:468-469
🌐 網路存取 (1)
審計單位: claude
分享與引用此報告
分享版本化評估報告、中性徽章、嵌入卡片與引用。Skillstore 只報告證據，不判斷該 Skill 是否安全。
複製報告連結
https://skillstore.io/skills/firebase-firestore-rules-creation/audits/1?utm_source=security_passport&utm_medium=share&utm_campaign=versioned_reportMarkdown 徽章
[](https://skillstore.io/skills/firebase-firestore-rules-creation?utm_source=security_passport_badge)HTML 徽章
<a href="https://skillstore.io/skills/firebase-firestore-rules-creation?utm_source=security_passport_badge"><img src="https://skillstore.io/badges/skills/firebase-firestore-rules-creation/security.svg" alt="Skillstore security assessment" loading="lazy"></a>嵌入卡片
<iframe src="https://skillstore.io/embed/skills/firebase-firestore-rules-creation.html" title="Skillstore Security Assessment" sandbox="allow-popups allow-popups-to-escape-sandbox" loading="lazy" referrerpolicy="no-referrer" width="420" height="180"></iframe>學術引用 (APA · BibTeX · CFF)
APA 引用
firebase. (2026). firestore-rules-creation security audit report (audit version 1) [Author version unspecified]. Skillstore. https://skillstore.io/skills/firebase-firestore-rules-creation/audits/1BibTeX 引用
@techreport{firebase-firebase-firestore-rules-creation-2026,
author = {firebase},
title = {firestore-rules-creation security audit report (audit version 1)},
institution = {Skillstore},
year = {2026},
number = {1},
url = {https://skillstore.io/skills/firebase-firestore-rules-creation/audits/1},
note = {Author version unspecified}
}CITATION.cff
cff-version: 1.2.0
message: "If you use this Skill, cite its author and this versioned security audit report."
title: "firestore-rules-creation security audit report (audit version 1)"
version: "unspecified"
type: report
authors:
- name: "firebase"
date-released: "2026-09-11"
url: "https://skillstore.io/skills/firebase-firestore-rules-creation/audits/1"
identifiers:
- type: other
value: "skillstore:firebase-firestore-rules-creation:audit:1"
description: "Skillstore immutable audit report identifier"
Skillstore 評分
評分依據 證據置信度: 中 55
架構
85
可維護性
87
內容
65
社群
87
規範符合度
你可以打造什麼
Build a new application policy
Create a starting rules file for a new Firestore application with authenticated ownership and schema validation.
Protect collaborative data
Define safe editor, viewer, owner, and administrator permissions for shared documents.
Harden an existing rules file
Refactor existing rules and test for update bypasses, role escalation, data leakage, and unsafe counters.
試試這些提示
Start a rules file
Review this project and create a prototype firestore.rules file. List your data model assumptions and require authentication by default.
Add document ownership
Create Firestore Rules for a posts collection. Authors can create, read, update, and delete only their own posts. Validate title, body, author ID, and timestamps.
Model role-based access
Design Firestore Rules for a workspace application with owners, editors, and viewers. Keep role fields immutable for non-owners and validate every update.
Test complex business logic
Refactor these Firestore Rules and perform the full attack checklist. Check counters, state transitions, collection queries, PII separation, and batch consistency.
最佳實務
- Provide real collection paths, field types, queries, and user roles before generating rules.
- Test rules in the Firebase Emulator Suite with allowed and denied requests.
- Review generated rules before deployment and repeat tests after each schema change.
避免
- Do not use generated rules unchanged when application requirements are uncertain.
- Do not store public profile data and private personal data in the same document.
- Do not grant broad read or write access merely to resolve permission errors.
常見問題
What does this skill create?
It creates or refines a prototype Firestore Rules file and documents assumptions, validation, and test scenarios.
Does it make Firestore Rules secure by itself?
No. You must review the rules against your application behavior and test them before production use.
Can it support public data?
Yes. Describe which collections and fields are public. Keep private data in separate documents or collections.
Does it validate existing application queries?
It can identify and account for query patterns found in the codebase, but you must test them with Firebase tooling.
Can it implement roles?
Yes. It can draft ownership and role-based policies while protecting role fields from self-escalation.
Does it deploy the rules?
It can prepare rules and recommend validation commands. You control deployment and must review the changes first.