Firebase Security Testing Tutorial for Beginners

New to Firebase security? This beginner-friendly tutorial teaches you everything you need to know about testing Firebase security rules, even if you've never done security testing before.

What is Firebase Security Testing?

Firebase security testing verifies that your security rules work as intended. You're checking:

• Who can read your data
• Who can write/modify data
• What data validation exists
• If users are properly isolated

Think of it like testing locks on doors - you want to make sure only the right people can get in.

Prerequisites

You'll need:

• A Firebase project (free tier is fine)
• Basic knowledge of Firebase (Realtime Database or Firestore)
• 15 minutes

Part 1: Understanding Your Current Security

Step 1: Find Your Security Rules

For Realtime Database:

1. Go to Firebase Console
2. Click "Realtime Database"
3. Click "Rules" tab

You'll see something like:

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

For Firestore:

1. Go to Firebase Console
2. Click "Firestore Database"
3. Click "Rules" tab

You'll see:

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write;
    }
  }
}

Step 2: Understand What These Mean

.read: true or allow read = Anyone can read .write: true or allow write = Anyone can write

This is the default Firebase gives you - and it's completely insecure for production!

Part 2: Your First Security Test

Test 1: Can Anyone Read Your Data?

Open your website in an incognito/private browser window (you're not logged in).

Open the browser console (F12) and paste:

For Realtime Database:

fetch('https://YOUR-PROJECT.firebaseio.com/users.json')
  .then(r => r.json())
  .then(data => {
    if (data) {
      console.log('⚠️ INSECURE: Anonymous users can read data!');
      console.log(data);
    } else {
      console.log('✅ SECURE: Data is protected');
    }
  });

For Firestore: You'll need Firebase SDK, but the concept is the same - try reading without being logged in.

Test 2: Can You Access Other Users' Data?

Log into your app as a test user. Then try:

// Try to read another user's data
const otherUserId = 'some-other-user-id';

firebase.database().ref(`users/${otherUserId}`).once('value')
  .then(snapshot => {
    if (snapshot.val()) {
      console.log('⚠️ INSECURE: You can read other users data!');
    }
  })
  .catch(err => {
    console.log('✅ SECURE: Access denied to other users');
  });

Part 3: Using Automated Testing

Manual testing is tedious. Let's use FireScan to test automatically.

Step 1: Install FireScan

go install github.com/JacobDavidAlcock/firescan/cmd/firescan@latest

Don't have Go? Download pre-compiled binary.

Step 2: Find Your Firebase Config

View your website source and find:

const firebaseConfig = {
  apiKey: "AIzaSyD...",        // Copy this
  projectId: "my-app-12345",   // And this
  // ...
};

Step 3: Run Your First Scan

# Start FireScan
firescan

# Configure your project
firescan > set projectID my-app-12345
firescan > set apiKey AIzaSyD...

# Test without logging in
firescan > scan --unauth

What the output means:

[RTDB] Vulnerability Found!
  ├── Severity:  Critical
  ├── Type:      RTDB
  └── Path:      users

This means anonymous users can access /users - that's bad!

[RTDB] Permission Denied
  └── Path:      admin

This is good - the path is protected.

Step 4: Test as a Logged-In User

# Create a test account
firescan > auth --create-account

# Scan everything
firescan > scan --all

Part 4: Fixing Common Issues

Issue 1: World-Readable Database

Your current rules:

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

Fixed rules:

{
  "rules": {
    ".read": "auth != null",
    ".write": "auth != null"
  }
}

What this does: Requires users to be logged in.

Issue 2: Users Can Access Each Other's Data

Current rules:

{
  "rules": {
    "users": {
      ".read": "auth != null",
      ".write": "auth != null"
    }
  }
}

Fixed rules:

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

What this does: Each user can only access their own data at /users/{their-uid}.

Part 5: Testing Your Fixes

After updating rules:

# Test again
firescan > scan --unauth
firescan > scan --all

You should now see "Permission Denied" for sensitive paths!

Common Beginner Mistakes

1. Not testing before deploying - Always test rules changes
2. Only testing while logged in - Test unauthenticated access too
3. Forgetting to update rules - Rules don't automatically improve
4. Not understanding rule syntax - Read Firebase docs carefully
5. Assuming defaults are secure - They're not!

Security Testing Checklist for Beginners

• [ ] Found your Firebase project ID and API key
• [ ] Located your security rules in Firebase Console
• [ ] Tested unauthenticated access (incognito window)
• [ ] Tested with a logged-in user
• [ ] Used FireScan for automated testing
• [ ] Fixed world-readable rules
• [ ] Added user isolation
• [ ] Re-tested after fixes
• [ ] Deployed updated rules to production

What's Next?

Now that you understand the basics:

• Learn about 10 common vulnerabilities
• Use the complete security checklist
• Set up automated testing in CI/CD

Need Help?

Stuck on something? Here are your options:

1. Free: Check the FireScan FAQ
2. Free: Read more blog tutorials
3. Paid: Get professional security assessment

Remember: Good security starts with testing. Make it a habit to test your Firebase rules regularly!

---

Found this helpful? Support FireScan to keep creating free tutorials.