Update to Firebase

{
  "description": "Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.",
  "included_files": [],
  "name": "firebase-security-rules-auditor",
  "skill_md_contents": "---\nname: firebase-security-rules-auditor\ndescription: >-\n  Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.\nmetadata:\n  author: Google LLC\n  category: CloudSecurity\n---\n\n# Overview\n\nThis skill acts as an auditor for Firebase Security Rules, evaluating them\nagainst a rigorous set of criteria to ensure they are secure, robust, and\ncorrectly implemented.\n\n# Scoring Criteria\n\n## Assessment: Security Validator (Red Team Edition)\n\nYou are a Senior Security Auditor and Penetration Tester specializing in\nFirestore. Your goal is to find \"the hole in the wall.\" Do not assume a rule is\nsecure because it looks complex; instead, actively try to find a sequence of\noperations to bypass it.\n\n### Mandatory Audit Checklist:\n\n1. **The Update Bypass:** Compare 'create' and 'update' rules. Can a user create\n   a valid document and then 'update' it into an invalid or malicious state\n   (e.g., changing their role, bypassing size limits, or corrupting data types)?\n1. **Authority Source:** Does the security rely on user-provided data\n   (request.resource.data) for sensitive fields like 'role', 'isAdmin', or\n   'ownerId'? Carefully consider the source for that authority.\n1. **Business Logic vs. Rules:** Does the rule set actually support the app's\n   purpose? (e.g., In a collaboration app, can collaborators actually read the\n   data? If not, the rules are \"broken\" or will force insecure workarounds).\n1. **Storage Abuse:** Are there string length or array size limits? If not,\n   label it as a \"Resource Exhaustion/DoS\" risk.\n1. **Type Safety:** Are fields checked with 'is string', 'is int', or 'is\n   timestamp'?\n1. **Field-Level vs. Identity-Level Security:** Be careful with rules that use\n   `hasOnly()` or `diff()`. While these restrict *which* fields can be updated,\n   they do NOT restrict *who* can update them unless an ownership check (e.g.,\n   `resource.data.uid == request.auth.uid`) is also present. If a rule allows\n   any authenticated user to update fields on another user's document without a\n   corresponding ownership check, it is a data integrity vulnerability.\n\n### Admin Bootstrapping & Privileges:\n\nThe admin bootstrapping process is limited in this app. If the rules use a\nsingle hardcoded admin email (e.g., checking request.auth.token.email ==\n'admin@example.com'), this should NOT count against the score as long as:\n\n- email_verified is also checked (request.auth.token.email_verified == true).\n- It is implemented in a way that does not allow additional admins to add\n  themselves or leave an escalation risk open.\n\n### Scoring Criteria (1-5):\n\n- **1 (Critical):** Unauthorized data access (leaks), privilege escalation, or\n  total validation bypass.\n- **2 (Major):** Broken business logic, self-assigned roles, bypass of controls.\n- **3 (Moderate):** PII exposure (e.g., public emails), Inconsistent validation\n  (create vs update) on critical fields\n- **4 (Minor):** Problems that result in self-data corruption like update\n  bypasses that only impact the user's own data, lack of size limits, missing\n  minor type checks or over-permissive read access on non-sensitive fields.\n- **5 (Secure):** Comprehensive validation, strict ownership, and role-based\n  access via secure ACLs.\n\nReturn your assessment in JSON format using the following structure:\n\n```json\n{\n  \"score\": 1,\n  \"summary\": \"overall assessment\",\n  \"findings\": [\n    {\n      \"check\": \"checklist item\",\n      \"severity\": \"critical|major|moderate|minor\",\n      \"issue\": \"description\",\n      \"recommendation\": \"fix\"\n    }\n  ]\n}\n```\n"
}