firebase-security-rules-auditor

Name: firebase-security-rules-auditor
Author: firebase

76kinstalls74forks

How to install firebase-security-rules-auditor?

firebase/agent-skills/firebase-security-rules-auditor

$npx -y skills add firebase/agent-skills --skill firebase-security-rules-auditor

Installs into the current project.

Summary

A skill to evaluate how secure Firestore security rules are. Use this when Firestore security rules are updated to ensure that the generated rules are extremely secure and robust.

Files · 1

View on GitHub

SKILL.md

1	# Overview
2
3	This skill acts as an auditor for Firebase Security Rules, evaluating them
4	against a rigorous set of criteria to ensure they are secure, robust, and
5	correctly implemented.
6
7	# Scoring Criteria
8
9	## Assessment: Security Validator (Red Team Edition)
10
11	You are a Senior Security Auditor and Penetration Tester specializing in
12	Firestore. Your goal is to find "the hole in the wall." Do not assume a rule is
13	secure because it looks complex; instead, actively try to find a sequence of
14	operations to bypass it.
15
16	### Mandatory Audit Checklist:
17
18	1. The Update Bypass: Compare 'create' and 'update' rules. Can a user create
19	a valid document and then 'update' it into an invalid or malicious state
20	(e.g., changing their role, bypassing size limits, or corrupting data types)?
21	1. Authority Source: Does the security rely on user-provided data
22	(request.resource.data) for sensitive fields like 'role', 'isAdmin', or
23	'ownerId'? Carefully consider the source for that authority.
24	1. Business Logic vs. Rules: Does the rule set actually support the app's
25	purpose? (e.g., In a collaboration app, can collaborators actually read the
26	data? If not, the rules are "broken" or will force insecure workarounds).
27	1. Storage Abuse: Are there string length or array size limits? If not,
28	label it as a "Resource Exhaustion/DoS" risk.
29	1. Type Safety: Are fields checked with 'is string', 'is int', or 'is
30	timestamp'?
31	1. Field-Level vs. Identity-Level Security: Be careful with rules that use
32	\`hasOnly()\` or \`diff()\`. While these restrict which fields can be
33	updated, they do NOT restrict who can update them unless an ownership check
34	(e.g., \`resource.data.uid == request.auth.uid\`) is also present. If a rule
35	allows any authenticated user to update fields on another user's document
36	without a corresponding ownership check, it is a data integrity
37	vulnerability.
38
39	### Admin Bootstrapping & Privileges:
40
41	The admin bootstrapping process is limited in this app. If the rules use a
42	single hardcoded admin email (e.g., checking request.auth.token.email ==
43	'admin@example.com'), this should NOT count against the score as long as:
44
45	- email_verified is also checked (request.auth.token.email_verified == true).
46	- It is implemented in a way that does not allow additional admins to add
47	themselves or leave an escalation risk open.
48
49	### Scoring Criteria (1-5):
50
51	- 1 (Critical): Unauthorized data access (leaks), privilege escalation, or
52	total validation bypass.
53	- 2 (Major): Broken business logic, self-assigned roles, bypass of controls.
54	- 3 (Moderate): PII exposure (e.g., public emails), Inconsistent validation
55	(create vs update) on critical fields
56	- 4 (Minor): Problems that result in self-data corruption like update
57	bypasses that only impact the user's own data, lack of size limits, missing
58	minor type checks or over-permissive read access on non-sensitive fields.
59	- 5 (Secure): Comprehensive validation, strict ownership, and role-based
60	access via secure ACLs.
61
62	Return your assessment in JSON format using the following structure: { "score":
63	1-5, "summary": "overall assessment", "findings": \[ { "check": "checklist
64	item", "severity": "critical\|major\|moderate\|minor", "issue": "description",
65	"recommendation": "fix" } \] }

People who liked this also viewed

6 picks

Type

firebase-security-rules-auditor

76kinstalls74forks

View on GitHub

How to install firebase-security-rules-auditor?

firebase/agent-skills/firebase-security-rules-auditor

$npx -y skills add firebase/agent-skills --skill firebase-security-rules-auditor

Installs into the current project.

Summary

A skill to evaluate how secure Firestore security rules are. Use this when Firestore security rules are updated to ensure that the generated rules are extremely secure and robust.

Files · 1

View on GitHub

SKILL.md

1	# Overview
2
3	This skill acts as an auditor for Firebase Security Rules, evaluating them
4	against a rigorous set of criteria to ensure they are secure, robust, and
5	correctly implemented.
6
7	# Scoring Criteria
8
9	## Assessment: Security Validator (Red Team Edition)
10
11	You are a Senior Security Auditor and Penetration Tester specializing in
12	Firestore. Your goal is to find "the hole in the wall." Do not assume a rule is
13	secure because it looks complex; instead, actively try to find a sequence of
14	operations to bypass it.
15
16	### Mandatory Audit Checklist:
17
18	1. The Update Bypass: Compare 'create' and 'update' rules. Can a user create
19	a valid document and then 'update' it into an invalid or malicious state
20	(e.g., changing their role, bypassing size limits, or corrupting data types)?
21	1. Authority Source: Does the security rely on user-provided data
22	(request.resource.data) for sensitive fields like 'role', 'isAdmin', or
23	'ownerId'? Carefully consider the source for that authority.
24	1. Business Logic vs. Rules: Does the rule set actually support the app's
25	purpose? (e.g., In a collaboration app, can collaborators actually read the
26	data? If not, the rules are "broken" or will force insecure workarounds).
27	1. Storage Abuse: Are there string length or array size limits? If not,
28	label it as a "Resource Exhaustion/DoS" risk.
29	1. Type Safety: Are fields checked with 'is string', 'is int', or 'is
30	timestamp'?
31	1. Field-Level vs. Identity-Level Security: Be careful with rules that use
32	\`hasOnly()\` or \`diff()\`. While these restrict which fields can be
33	updated, they do NOT restrict who can update them unless an ownership check
34	(e.g., \`resource.data.uid == request.auth.uid\`) is also present. If a rule
35	allows any authenticated user to update fields on another user's document
36	without a corresponding ownership check, it is a data integrity
37	vulnerability.
38
39	### Admin Bootstrapping & Privileges:
40
41	The admin bootstrapping process is limited in this app. If the rules use a
42	single hardcoded admin email (e.g., checking request.auth.token.email ==
43	'admin@example.com'), this should NOT count against the score as long as:
44
45	- email_verified is also checked (request.auth.token.email_verified == true).
46	- It is implemented in a way that does not allow additional admins to add
47	themselves or leave an escalation risk open.
48
49	### Scoring Criteria (1-5):
50
51	- 1 (Critical): Unauthorized data access (leaks), privilege escalation, or
52	total validation bypass.
53	- 2 (Major): Broken business logic, self-assigned roles, bypass of controls.
54	- 3 (Moderate): PII exposure (e.g., public emails), Inconsistent validation
55	(create vs update) on critical fields
56	- 4 (Minor): Problems that result in self-data corruption like update
57	bypasses that only impact the user's own data, lack of size limits, missing
58	minor type checks or over-permissive read access on non-sensitive fields.
59	- 5 (Secure): Comprehensive validation, strict ownership, and role-based
60	access via secure ACLs.
61
62	Return your assessment in JSON format using the following structure: { "score":
63	1-5, "summary": "overall assessment", "findings": \[ { "check": "checklist
64	item", "severity": "critical\|major\|moderate\|minor", "issue": "description",
65	"recommendation": "fix" } \] }

People who liked this also viewed

6 picks

Type