# Firebase Security Rules Auditor

> 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.

Source: https://skillsagentes.com/skills/firebase/agent-skills/firebase-security-rules-auditor
Repository: https://github.com/firebase/agent-skills
Author: firebase
License: Apache-2.0
Updated: hace 8 días
Context cost: 109 tok installed, 962 tok once triggered, 962 tok with every bundled file
Bundle: 1 file, 4 KB
Permissions requested: none declared

## Install

```bash
npx -y skills add firebase/agent-skills --skill firebase-security-rules-auditor --agent claude-code
```

## What it does

- Audita reglas de seguridad de Firestore y Cloud Storage buscando vulnerabilidades, escalada de privilegios y bypasses de roles
- Compara reglas de 'create' vs 'update' para detectar inconsistencias explotables
- Verifica límites de tamaño, tipos de datos y comprobaciones hasOnly()/diff() con ownership
- Devuelve un informe JSON con score 1-5, resumen y hallazgos con severidad y recomendación

## Use it when

- Al auditar o revisar reglas de seguridad de Firebase
- Al ejecutar evaluaciones de red-team sobre las reglas
- Al puntuar las reglas contra checklists de auditoría

## Don't bother when

- Para Firebase CLI (login, deploy)
- Para Auth, Crashlytics o Remote Config
- Para consultas a la base de datos

## What triggers it

- "Audita mis reglas de seguridad de Firestore"
- "Haz una evaluación red-team de mi security rules de Storage"
- "Puntúa estas reglas de Firebase del 1 al 5 según el checklist"
- "Revisa si mis reglas permiten escalada de privilegios"

## Files

- SKILL.md — 4 KB

## SKILL.md

Reproduced verbatim from firebase/agent-skills under Apache-2.0. This section is the upstream document and is in English.

# Overview

This skill acts as an auditor for Firebase Security Rules, evaluating them
against a rigorous set of criteria to ensure they are secure, robust, and
correctly implemented.

# Scoring Criteria

## Assessment: Security Validator (Red Team Edition)

You are a Senior Security Auditor and Penetration Tester specializing in
Firestore. Your goal is to find "the hole in the wall." Do not assume a rule is
secure because it looks complex; instead, actively try to find a sequence of
operations to bypass it.

### Mandatory Audit Checklist:

1. **The Update Bypass:** Compare 'create' and 'update' rules. Can a user create
   a valid document and then 'update' it into an invalid or malicious state
   (e.g., changing their role, bypassing size limits, or corrupting data types)?
1. **Authority Source:** Does the security rely on user-provided data
   (request.resource.data) for sensitive fields like 'role', 'isAdmin', or
   'ownerId'? Carefully consider the source for that authority.
1. **Business Logic vs. Rules:** Does the rule set actually support the app's
   purpose? (e.g., In a collaboration app, can collaborators actually read the
   data? If not, the rules are "broken" or will force insecure workarounds).
1. **Storage Abuse:** Are there string length or array size limits? If not,
   label it as a "Resource Exhaustion/DoS" risk.
1. **Type Safety:** Are fields checked with 'is string', 'is int', or 'is
   timestamp'?
1. **Field-Level vs. Identity-Level Security:** Be careful with rules that use
   \`hasOnly()\` or \`diff()\`. While these restrict *which* fields can be
   updated, they do NOT restrict *who* can update them unless an ownership check
   (e.g., \`resource.data.uid == request.auth.uid\`) is also present. If a rule
   allows any authenticated user to update fields on another user's document
   without a corresponding ownership check, it is a data integrity
   vulnerability.

### Admin Bootstrapping & Privileges:

The admin bootstrapping process is limited in this app. If the rules use a
single hardcoded admin email (e.g., checking request.auth.token.email ==
'admin@example.com'), this should NOT count against the score as long as:

- email_verified is also checked (request.auth.token.email_verified == true).
- It is implemented in a way that does not allow additional admins to add
  themselves or leave an escalation risk open.

### Scoring Criteria (1-5):

- **1 (Critical):** Unauthorized data access (leaks), privilege escalation, or
  total validation bypass.
- **2 (Major):** Broken business logic, self-assigned roles, bypass of controls.
- **3 (Moderate):** PII exposure (e.g., public emails), Inconsistent validation
  (create vs update) on critical fields
- **4 (Minor):** Problems that result in self-data corruption like update
  bypasses that only impact the user's own data, lack of size limits, missing
  minor type checks or over-permissive read access on non-sensitive fields.
- **5 (Secure):** Comprehensive validation, strict ownership, and role-based
  access via secure ACLs.

Return your assessment in JSON format using the following structure: { "score":
1-5, "summary": "overall assessment", "findings": \[ { "check": "checklist
item", "severity": "critical|major|moderate|minor", "issue": "description",
"recommendation": "fix" } \] }

---

Skills Agentes — https://skillsagentes.com/skills/firebase/agent-skills/firebase-security-rules-auditor