Auth Bypass on Firebase
How Auth Bypass Manifests in Firebase
Firebase authentication bypass vulnerabilities occur when developers misconfigure security rules or improperly handle authentication state, allowing unauthorized access to protected resources. These issues are particularly dangerous because Firebase's client-side SDKs make it easy to accidentally expose sensitive data or functionality.
The most common Firebase auth bypass pattern involves insecure security rules. Consider this vulnerable Firestore configuration:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, write: if true; // <-- DANGEROUS
}
}
}This rule allows anyone to read or write any user document, completely bypassing authentication. A more subtle variant:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read: if true; // Read access to all
allow write: if request.auth.uid == userId; // Write only to own docs
}
}
}While this seems secure, it allows enumeration of all user IDs through read access, enabling targeted attacks.
Client-side authentication checks are another major vulnerability. Developers often write code like:
const db = firebase.firestore();
const userId = firebase.auth().currentUser.uid;
// INSECURE: client-side check only
if (userId) {
db.collection('users').doc(userId).get().then(doc => {
// Process user data
});
}This code trusts the client to enforce authentication, but anyone can modify client-side JavaScript or create requests that bypass these checks entirely. Security rules must always be enforced server-side.
Another Firebase-specific bypass occurs with custom claims. Developers sometimes write:
const claims = await admin.auth().getUser(uid).customClaims;
if (claims && claims.admin) {
// Grant admin access
}If custom claims aren't properly validated or are manipulated through token refresh timing issues, attackers can escalate privileges. The correct approach uses security rules:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /admin/{document=**} {
allow read, write: if request.auth.token.admin == true;
}
}
}Token manipulation attacks target Firebase's JWT handling. If developers don't properly validate token integrity or expiration, attackers can reuse captured tokens or modify claims. Firebase Admin SDK usage must be restricted to server-side code only:
// SERVER-SIDE ONLY
const admin = require('firebase-admin');
const uid = await admin.auth().verifyIdToken(idToken);
Never expose Admin SDK on client-side code, as this provides complete database access.
Firebase-Specific Detection
Detecting Firebase auth bypass requires examining both configuration and runtime behavior. For security rules, use the Firebase Emulator Suite to test rule sets against various authentication states:
const firebase = require('@firebase/rules-unit-testing');
describe('Security Rules', () => {
it('should prevent unauthorized access', async () => {
const db = await firebase.initializeTestApp({
projectId: 'demo-project',
auth: { uid: 'hacker', email: '[email protected]' }
}).firestore();
const doc = db.collection('users').doc('admin');
await firebase.assertFails(doc.get());
});
});For runtime detection, middleBrick's Firebase-specific scanning identifies auth bypass patterns by testing endpoints with various authentication states and analyzing responses. The scanner attempts unauthenticated requests to protected endpoints and checks for:
- Unexpected data exposure when no authentication is provided
- Authentication bypass through parameter manipulation
- Token validation weaknesses
- Custom claim validation issues
- Security rule misconfigurations
middleBrick's Firebase detection includes specialized checks for:
// Example of what middleBrick tests for:
const testAuthBypass = async (url) => {
// Test unauthenticated access
const unauthResponse = await fetch(url, { credentials: 'omit' });
// Test with invalid tokens
const invalidTokenResponse = await fetch(url, {
headers: { Authorization: 'Bearer invalid.token.here' }
// Test with manipulated claims
const manipulatedClaims = await fetch(url, {
headers: { Authorization: 'Bearer token-with-altered-claims' }
});
return { unauthResponse, invalidTokenResponse, manipulatedClaims };
};Firebase's built-in logging and monitoring can also help detect auth bypass attempts. Enable Audit Logs in the Firebase Console and watch for:
- Repeated failed authentication attempts
- Access to protected resources from unexpected locations
- Unusual token validation failures
- Requests with manipulated claims
For comprehensive detection, integrate middleBrick's continuous monitoring into your Firebase development workflow. The scanner can be run as a GitHub Action that fails builds when auth bypass vulnerabilities are detected:
name: Firebase Security Scan
on: [push, pull_request]
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run middleBrick scan
run: middlebrick scan https://your-firebase-app.firebaseio.com --output jsonFirebase-Specific Remediation
Firebase auth bypass remediation requires a defense-in-depth approach combining proper security rules, authentication validation, and monitoring. Start with comprehensive security rules that follow the principle of least privilege:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Public data
match /public/{document=**} {
allow read: if true;
allow write: if false;
}
// User-specific data
match /users/{userId} {
allow read, write: if request.auth.uid == userId;
}
// Admin data
match /admin/{document=**} {
allow read, write: if request.auth.token.admin == true;
}
// Nested secure data
match /projects/{projectId} {
allow read: if true; // Public project info
allow write: if request.auth.uid == resource.data.ownerId;
match /sensitive/{docId} {
allow read, write: if request.auth.uid == resource.data.ownerId;
}
}
}
}Always validate authentication server-side. In Firebase Functions or Cloud Run:
const functions = require('firebase-functions');
const admin = require('firebase-admin');
admin.initializeApp();
exports.secureEndpoint = functions.https.onRequest(async (req, res) => {
try {
const token = req.headers.authorization?.replace('Bearer ', '');
if (!token) {
return res.status(401).json({ error: 'Missing token' });
}
const decoded = await admin.auth().verifyIdToken(token, true);
if (!decoded) {
return res.status(403).json({ error: 'Invalid token' });
}
// Now use decoded.uid for authorization
const userId = decoded.uid;
// Continue with business logic
} catch (error) {
console.error('Auth verification failed:', error);
return res.status(500).json({ error: 'Internal server error' });
}
});For client-side security, implement proper authentication state handling:
import { getAuth, onAuthStateChanged } from 'firebase/auth';
import { initializeApp } from 'firebase/app';
const firebaseConfig = { /* your config */ };
const app = initializeApp(firebaseConfig);
const auth = getAuth(app);
onAuthStateChanged(auth, (user) => {
if (user) {
// User is signed in, update UI accordingly
console.log('User ID:', user.uid);
} else {
// No user is signed in
console.log('No authenticated user');
}
});Implement comprehensive monitoring and alerting for auth bypass attempts:
const functions = require('firebase-functions');
const admin = require('firebase-admin');
admin.initializeApp();
exports.logAuthFailures = functions.firestore.document('audit/{docId}')
.onCreate(async (snap, context) => {
const data = snap.data();
if (data.status === 'failed' && data.reason === 'unauthorized') {
console.log('Auth bypass attempt detected:', data);
// Send alert to monitoring system
}
});Use Firebase's built-in security features effectively:
- Enable App Check to verify requests come from your actual app
- Use Firebase Hosting rules to restrict API access to authenticated users
- Implement proper CORS policies for your Firebase Functions
- Set up proper token expiration and refresh policies
Regular security audits are essential. Use middleBrick's continuous scanning to detect auth bypass vulnerabilities before they reach production. The scanner can be configured to run on a schedule and alert your team when new vulnerabilities are discovered.
Related CWEs: authentication
| CWE ID | Name | Severity |
|---|---|---|
| CWE-287 | Improper Authentication | CRITICAL |
| CWE-306 | Missing Authentication for Critical Function | CRITICAL |
| CWE-307 | Brute Force | HIGH |
| CWE-308 | Single-Factor Authentication | MEDIUM |
| CWE-309 | Use of Password System for Primary Authentication | MEDIUM |
| CWE-347 | Improper Verification of Cryptographic Signature | HIGH |
| CWE-384 | Session Fixation | HIGH |
| CWE-521 | Weak Password Requirements | MEDIUM |
| CWE-613 | Insufficient Session Expiration | MEDIUM |
| CWE-640 | Weak Password Recovery | HIGH |