Firebase Code Validation

Overview

This sub-skill validates existing Firebase code against proven patterns and security best practices. It checks configuration, rules, architecture consistency, authentication, testing, and production readiness.

Key principles:

• Validate against chosen architecture patterns
• Check security rules thoroughly
• Verify test coverage exists
• Review production readiness

When This Sub-Skill Applies

• Conducting code review of Firebase project
• Auditing security implementation
• Preparing for production deployment
• User says: "review firebase", "validate", "audit firebase", "check firebase code"

Do not use for:

• Initial setup → firebase-development:project-setup
• Adding features → firebase-development:add-feature
• Debugging active errors → firebase-development:debug

TodoWrite Workflow

Create checklist with these 9 steps:

Step 1: Check firebase.json Structure

Validate required sections:

• hosting - Array or object present
• functions - Source directory, runtime, predeploy hooks
• firestore - Rules and indexes files
• emulators - Local development config

Check hosting pattern matches implementation (site:, target:, or single).

Reference: docs/examples/multi-hosting-setup.md

Step 2: Validate Emulator Configuration

Critical settings:

json
{
  "emulators": {
    "singleProjectMode": true,
    "ui": { "enabled": true }
  }
}

Verify all services in use have emulator entries.

Reference: docs/examples/emulator-workflow.md

Step 3: Review Firestore Rules

Check for:

• Helper functions at top (isAuthenticated(), isOwner())
• Consistent security model (server-write-only OR client-write-validated)
• diff().affectedKeys().hasOnly([...]) for client writes
• Collection group rules if using collectionGroup() queries
• Default deny rule at bottom

Reference: docs/examples/firestore-rules-patterns.md

Step 4: Validate Functions Architecture

Identify pattern in use:

• Express: Check middleware/, tools/, CORS, health endpoint
• Domain-Grouped: Check exports, domain boundaries, shared/
• Individual: Check one function per file structure

Critical: Don't mix patterns. Verify consistency throughout.

Reference: docs/examples/express-function-architecture.md

Step 5: Check Authentication Implementation

For API Keys:

• Middleware validates key format with project prefix
• Uses collectionGroup('apiKeys') query
• Checks active: true flag
• Attaches userId to request

For Firebase Auth:

• Functions check request.auth.uid
• Role lookups use Firestore user document
• Client connects to auth emulator in development

Reference: docs/examples/api-key-authentication.md

Step 6: Verify ABOUTME Comments

All .ts files should start with:

typescript
// ABOUTME: Brief description of what this file does
// ABOUTME: Second line with additional context

bash
grep -L "ABOUTME:" functions/src/**/*.ts  # Find missing

Step 7: Review Test Coverage

Check for:

• Unit tests: functions/src/__tests__/**/*.test.ts
• Integration tests: functions/src/__tests__/emulator/**/*.test.ts
• vitest.config.ts and vitest.emulator.config.ts exist
• Coverage threshold met (60%+)

bash
npm test && npm run test:coverage

Step 8: Validate Error Handling

All handlers must:

• Use try-catch blocks
• Return { success: boolean, message: string, data?: any }
• Use proper HTTP status codes (400, 401, 403, 500)
• Log errors with console.error
• Validate input before processing

Step 9: Security and Production Review

Security checks:

• No secrets in code (grep -r "apiKey.*=" functions/src/)
• .env files in .gitignore
• No allow read, write: if true; in rules
• Sensitive fields protected from client writes

Production checks:

• npm audit clean
• Build succeeds: npm run build
• Tests pass: npm test
• Correct project in .firebaserc
• Indexes defined for complex queries

Validation Checklists

Hosting Pattern

• ] Pattern matches firebase.json config
• ] Sites/targets exist in Firebase Console
• ] Rewrites reference valid functions
• ] Emulator ports configured

Authentication Pattern

• ] Auth method matches security model
• ] Middleware/checks implemented correctly
• ] Environment variables documented
• ] Emulator connection configured

Security Model

• ] Server-write-only: All allow write: if false;
• ] Client-write: diff().affectedKeys() validation
• ] Default deny rule present
• ] Helper functions used consistently

Common Issues

| Issue | Fix | |-------|-----| | Missing singleProjectMode | Add to emulators config | | No default deny rule | Add match /{document=**} { allow: if false; } | | Mixed architecture | Migrate to consistent pattern | | Missing ABOUTME | Add 2-line header to all .ts files | | No integration tests | Add emulator tests for workflows | | Inconsistent response format | Standardize to {success, message, data?} | | No error handling | Add try-catch to all handlers | | Secrets in code | Move to environment variables |

Integration with Superpowers

For general code quality review beyond Firebase patterns, invoke superpowers:requesting-code-review.

Output

After validation, provide:

• Summary of findings
• Issues categorized by severity (critical, important, nice-to-have)
• Recommendations for remediation
• Confirmation of best practices compliance

Pattern References

• Hosting: docs/examples/multi-hosting-setup.md
• Auth: docs/examples/api-key-authentication.md
• Functions: docs/examples/express-function-architecture.md
• Rules: docs/examples/firestore-rules-patterns.md
• Emulators: docs/examples/emulator-workflow.md