Skip to main content

Firebase Realtime Database Security Vulnerabilities

Executive Summary​

Date: November 18, 2025 Project: Pivot (pivot-not-production-project & pivot-inc) Severity: CRITICAL

The Firebase Realtime Database for Pivot has catastrophic security rules that allow ANY authenticated user to read and write the ENTIRE database across all companies. This means:

  • Any employee from Restaurant A can access all data from Restaurant B, C, D, etc.
  • Any authenticated user can delete the entire database
  • Competitors can steal all customer data
  • Malicious actors can modify schedules, payroll, and sensitive information

This vulnerability exists in BOTH staging and production environments.

Current Security Rules (VULNERABLE)​

Location: /pivot/database.rules.json

{
  "rules": {
    ".read": "auth != null",  // ← ANY authenticated user can read EVERYTHING
    ".write": "auth != null", // ← ANY authenticated user can write EVERYTHING
    ...
  }
}

Vulnerability Details​

1. Global Read/Write Access (Lines 3-4)​

Current Rule:

".read": "auth != null",
".write": "auth != null"

What This Means:

  • Any user who signs up and gets a Firebase authentication token can access ALL data
  • No company isolation
  • No role-based access control
  • No data scoping

Attack Scenarios​

Scenario 1: Cross-Company Data Breach

  1. Malicious actor signs up as an employee at Restaurant A
  2. Gets Firebase authentication token
  3. Uses Firebase SDK or REST API to read:
    • /Companies → All company data (Restaurant A, B, C, D…)
    • /Employees → All employee records across all companies
    • /Messages → All chat messages across all companies
    • /Schedules → All scheduling data
    • /Passwords → All company access codes

Scenario 2: Complete Data Destruction

Any authenticated user can execute:

firebase.database().ref('/').remove() // Deletes EVERYTHING

Or selectively delete:

firebase.database().ref('/Companies').remove()  // All companies gone
firebase.database().ref('/Employees').remove()  // All employees gone
firebase.database().ref('/Messages').remove()   // All messages gone

Scenario 3: Data Manipulation

Employee from Restaurant A can:

  • Modify schedules for Restaurant B
  • Change employee permissions in other companies
  • Alter payroll data for competitors
  • Inject fake employees or data

Scenario 4: Competitor Intelligence

  1. Competitor signs up with fake credentials
  2. Downloads entire database
  3. Analyzes:
    • All restaurant operations
    • Employee count and wages
    • Customer patterns
    • Business metrics

2. Unauthenticated Write Access (Lines 6-7)​

Current Rule:

"Support": {
  ".write": true  // WORSE - anyone can write without authentication!
}

What This Means:

  • The /Support node allows ANYONE (even without authentication) to write data
  • No protection whatsoever
  • Can be abused for spam, injection attacks, or denial of service

3. Company Access Codes in Database (Lines 55-57)​

Current Rule:

"Passwords": {
  ".indexOn": ["password"]  // Company codes are stored AND indexed!
}

Investigation Findings:

  • The /Passwords node contains 159 entries with company access codes
  • These are simple join codes (e.g., "bonbo", "winni", "SoSof") that employees use to join companies
  • Currently readable by ANY authenticated user
  • Indexed by password value for easy lookup

What This Means:

  • Any authenticated user can read all company access codes
  • They can use these codes to join ANY company without proper invitation
  • Company owners have no control over who joins their company
  • Competitors can infiltrate any company by using leaked codes

Code Usage (pivot/src/routes/CompanySettings/index.js):

// When creating a company, code is stored
firebase.database().ref('Passwords/' + companyId).update({ password })

// Code validation checks if code already exists
firebase.database().ref('Passwords/')
  .orderByChild('password')
  .equalTo(password)
  .once('value')

4. Public Version Information (Lines 66-69)​

Current Rule:

"VersionWeb": {
  ".read": true,
  ".write": true  // Anyone can modify version info
}

What This Means:

  • Anyone can read version information (minor issue)
  • Anyone can WRITE to version information (medium issue)
  • Could be used to trick users into downloading malicious versions

Impact Assessment​

Data Exposed​

All of the following data is currently accessible to ANY authenticated user:

  • ✅ All company information
  • ✅ All employee records (names, emails, phone numbers, addresses)
  • ✅ All messages and chat history
  • ✅ All schedules and availability
  • ✅ All payroll and integration data
  • ✅ All company access codes (159 companies)
  • ✅ All applicant information
  • ✅ All notifications
  • ✅ All POS integration settings (Veloce, Lightspeed, MaitreD, etc.)
  • ✅ All API keys and tokens

Business Impact​

Data Privacy Violation

  • GDPR, CCPA, and other privacy law violations
  • Legal requirement to notify affected users in many jurisdictions

Competitive Risk

  • Competitors can steal all business intelligence
  • Access to proprietary scheduling algorithms
  • Employee wage data exposure

Reputational Damage

  • Loss of customer trust
  • Negative press coverage potential
  • Impact on customer acquisition

Legal Liability

  • Lawsuits from affected companies and employees
  • Regulatory investigations
  • Potential class action lawsuit

Financial Loss

  • Potential regulatory fines and compensation
  • Legal defense costs
  • Customer churn

Technical Impact​

Complete Database Destruction

  • Any user can delete everything
  • No automated backups may exist for real-time changes
  • Potential for catastrophic data loss

Data Integrity

  • Any user can modify any data
  • No audit trail for unauthorized changes
  • Impossible to trust data accuracy

Availability

  • Malicious actors can cause denial of service
  • Mass data deletion or corruption
  • Service disruption for all customers

Audit Trail

  • No way to prevent or track unauthorized access
  • Cannot determine who accessed what data
  • Forensic investigation would be extremely difficult

Affected Environments​

Staging Environment​

Production Environment​

  • Project: pivot-inc
  • Database URL: https://pivot-inc.firebaseio.com
  • Status: VULNERABLE (assumed - same rules file)
  • Investigation Status: Not yet investigated (requires explicit permission)

Root Cause Analysis​

Why This Happened​

  1. Default Firebase Rules: Firebase starts with public rules, meant to be replaced
  2. No Security Review: Rules were never reviewed for security implications
  3. No Testing: No automated security testing in place
  4. Rapid Development: Security took backseat to feature development
  5. Knowledge Gap: Team may not have been aware of security best practices

Why It Persists​

  1. No Monitoring: No alerts for security rule violations
  2. No Audit: No regular security audits
  3. No Testing: No tests that would catch this vulnerability
  4. Works Fine: Application functions correctly despite the vulnerability
  5. Not Obvious: Vulnerability is not visible in normal application usage

Timeline​

  • Unknown: Vulnerable rules deployed (likely from project inception)
  • November 18, 2025: Vulnerability discovered during security analysis
  • November 20, 2025: Investigation completed, findings documented
  • Current Status: ACTIVE VULNERABILITY - No fix deployed yet

Recommendations​

See Proposed Solution for detailed remediation steps.

Immediate Actions Required​

  1. DO NOT DEPLOY CHANGES TO PRODUCTION YET

    • Current rules are insecure but at least known
    • New rules need thorough testing in staging
    • Incorrect rules could lock out legitimate users

  2. Investigate Production Environment

    • Determine if production has the same vulnerability
    • Check if any unauthorized access has occurred
    • Review access logs if available

  3. Implement Secure Rules in Staging

    • Deploy proposed security rules to staging
    • Test all user scenarios
    • Monitor for 24-48 hours

  4. Remove or Secure Company Access Codes

    • Decide: Keep codes with proper security or migrate to email invitations
    • Implement proper access controls
    • Consider migrating to Firebase Dynamic Links

References​