Vercel + Firebase Security
Vercel's serverless environment and Firebase's real-time backend are a popular pairing. Admin SDK credentials in Vercel environment variables and unprotected Firestore rules are two distinct risks that both need attention.
Why Vercel + Firebase?
Next.js apps deployed on Vercel commonly use Firebase for auth, Firestore for data, and Storage for files. Vercel's serverless functions host Firebase Admin SDK operations. This creates a two-layer security surface: client SDK rules and server-side credential management.
Common Vulnerabilities
These are the security issues we find most often in Vercel apps using Firebase.
NEXT_PUBLIC_ Prefix on Firebase Admin Credentials
Adding NEXT_PUBLIC_ to Firebase service account environment variables exposes Admin SDK credentials to every browser visitor, bypassing all Security Rules.
Firestore Test Mode Rules
Client-side Firestore access still depends on Security Rules. A Vercel deployment does not add any protection — test mode rules remain fully exploitable from the browser.
Service Account JSON Committed to Repo
Teams deploying to Vercel sometimes commit serviceAccountKey.json to the repository for convenience, exposing Admin SDK credentials in version control.
Preview Deployment Firebase Access
Vercel preview deployments use the same environment variables as production, meaning preview builds have full Firebase Admin SDK access to the production database.
What We Check for Vercel + Firebase
Environment Variable Prefix Audit
Verify no Firebase Admin credentials use the NEXT_PUBLIC_ prefix that exposes them to the client bundle.
Security Rules Verification
Test Firestore rules as an unauthenticated user to confirm test mode is not in place.
Credential Exposure Scan
Scan the client-side JavaScript bundle for service account JSON or private key strings.
Preview Environment Isolation
Check whether preview deployments use a separate Firebase project from production.
Quick Security Wins
Apply these fixes right now to improve your security.
Audit every NEXT_PUBLIC_ variable — Firebase Admin credentials must never have this prefixAdd serviceAccountKey.json to .gitignore and rotate credentials if it was ever committedUse separate Vercel environment variable scopes: production-only for Firebase Admin credentialsWrite and deploy Firestore Security Rules independently: firebase deploy --only firestore:rulesSet up a separate Firebase project for Vercel preview deploymentsThe Bottom Line
Vercel + Firebase is a secure stack when both layers are properly configured: Admin SDK credentials must stay server-side without the NEXT_PUBLIC_ prefix, and Firestore Security Rules must be written and deployed independently of your Vercel build pipeline.
Secure Your Vercel + Firebase App
Find Security Rules misconfigurations, exposed credentials, and other vulnerabilities before attackers do.
Start Security ScanFrequently Asked Questions
Why would a Vercel deployment expose Firebase Admin credentials?
Vercel environment variables prefixed with NEXT_PUBLIC_ are embedded into the client-side JavaScript bundle at build time. If FIREBASE_SERVICE_ACCOUNT is accidentally prefixed NEXT_PUBLIC_, its value ships to every user's browser where it can be extracted.
Do Firestore Security Rules still apply when using Vercel serverless functions?
Only for client SDK calls. When your Vercel serverless function uses the Firebase Admin SDK, it bypasses Security Rules entirely — that's by design. Client-side Firestore calls from the browser still go through Security Rules normally.
Should Vercel preview deployments use the same Firebase project?
For production apps, no. Create a dedicated Firebase project for development and preview. Set Vercel environment variable scope to 'Production Only' for the production Firebase credentials.
How do I pass Firebase Admin credentials to Vercel securely?
Store the service account JSON as a Vercel environment variable (without NEXT_PUBLIC_). In your serverless function, parse it: const serviceAccount = JSON.parse(process.env.FIREBASE_SERVICE_ACCOUNT). Never commit the JSON file to your repository.