Forem: Architect

Managing development, staging and production environments in firebase

Architect — Mon, 16 Feb 2026 14:51:59 +0000

Hello world!

This is the second post of Building Firebase Apps with Architect series that i have started to help other fellow engineers and founders. Building products has gotten much easier due to the vibe coding platforms and its a very commonly accepted notion that building is just 20% of effort, rest 80% is marketing and promotion, which tbh, i completely agree with, but writing code to launch a product without considering the long term vision for your codebase may work in the short term, but it hinders the growth as you move past the validation phase, as you need to build and test features at a good speed.

In this post, i want to talk about how to setup different environments when building an saas app. The idea is to have a common codebase and have it configured in a way so that when deployed across different environments, it helps you test and build things in complete isolation from other environments. This way, its incredibly useful and safe as we don’t have to experiment in the production app.

Building Firebase Apps with Architect Series

Local development with Firebase

When building an app with firebase as its backend, we usually use firebase functions for its backend apis and firestore for the No SQL database, both of these things are extremely straightforward to setup and use.

Firebase comes with an emulator to emulate most the the backend services that are needed to build an saas app, and there are a few ways you can setup your codebase to use firebase, here are few of the ways to use firebase as a backend service

Use Client SDK

In your client app(web, android, iOS), you can just use firestore client SDK to create, update and delete data, you can read more about this approach here, NOTE: with this approach it is mandatory to setup the correct firebase rules so others can’t abuse your data and app.

Use Firebase Functions

Second approach is to use firebase functions as backend server and write functions that act as a api for your client apps to use, in this approach, client apps can use the firebase client SDK to call the function or write their own custom api handler to make the network calls to firebase functions api endpoints. Here is how to do it in code

Using Firebase Client SDK

import { getFunctions, httpsCallable } from "firebase/functions";

const functions = getFunctions();
const addMessage = httpsCallable(functions, 'addMessage');
addMessage({ text: messageText })
  .then((result) => {
    // Read result of the Cloud Function.
    /** @type {any} */
    const data = result.data;
    const sanitizedMessage = data.text;
  });

Using a custom api handler to make api calls

// Defining API Client to make api calls
export const apiClient = async (payload: StandardPayload) => {
  await getAuth().authStateReady();
  const user = getAuth().currentUser;
  const authToken = user ? await user.getIdToken(/* forceRefresh= */ false) : null;
  const res = await fetch('https://fn-6754.us-central1.run.app', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      ...(authToken ? { 'Authorization': `Bearer ${authToken}` } : {}),
    },
    body: JSON.stringify({ data: payload })
  });

  const body = await res.json();
  if (res.status !== 200) throw Error(body.error.message || 'Something went wrong!')
  return { data: body?.result };
};

// Making the api call to fetch data
import { apiClient } from "@/app/utils/apiClient"
const response = await apiClient(data);

IMPORTANT: You should attach a custom domain to your firebase functions, this will be helpful in short term and long term both, I have talked about it in my another post here.

Steps of pointing a custom domain to your functions is also different, with v2 functions, you can do it from the google cloud console here, For v1 functions, have a look at these two resources from Google, Blog, Video

Once you have mapped the custom domain with your firebase function, there are different ways to use the domain with the above two approaches with making the api call.

With the client SDK approach, you need to pass your domain to getFunctions call before you can make the call, here is how you do it in code

import { httpsCallable } from "firebase/functions";

export const firebaseApp = initializeApp(FIREBASE_CONFIG);
export const functions = getFunctions(firebaseApp, 'https://www.example.com');

const api = httpsCallable(functions, 'function_name');
api({ data: { hello: 'world' } })
  .then((result) => {
    console.log('api result', result);
  }).catch(error => { console.log('api error', error); });

With the custom api handler approach, you can just pass your domain into the fetch like this

export const apiClient = async (payload: StandardPayload) => {
  // ... some code, check the complete definition above
  const res = await fetch('https://www.example.com', OPTIONS);
  // ... some more code
};

Managing Environment Variables

When you have the same code base for all the environments, you need some identifiers in code to identify the environments and tweak code accordingly. To solve this, we use environment variables, they are called environment variables because they have different values for all the environments. Lets have a look at how to setup environment variables in frontend and backend codebases

Managing Environment Variables in Frontend Codebase

We will use the NextJS react frontend framework to see how to setup environment variables, but these approaches will work across other frontend frameworks too.

Environment variables are usually inject into the codebase during build phase by passing them in the build command, and here is how you do it.

  "scripts": {
    "dev": "NEXT_PUBLIC_ENV=development next dev --turbopack",
    "build": "NEXT_PUBLIC_ENV=production next build --turbopack",
    "build:stage": "NEXT_PUBLIC_ENV=staging next build --turbopack"
  }

IMPORTANT

When we are passing the variables into the build command, we need to make sure that these variables are injected into client and server code both of the frontend codebase, and Vercel only allows the environment variables defined with NEXT_PUBLIC_ prefix to be injected into both, the client side code and the server side code, if you don’t use the prefix, the variable will only be available when your frontend code is running on the server side, and will resolve to undefined when accessed on client(browser).

Once you have defined and injected the environment variables, you need to access them in code to pick different configurations for different environments. Here are some of the examples of picking the right configurations for their respective environments.

Initialising Google Analytics only for Production Environment

    <html lang="en">
      <body>
      </body>
      {
        process.env.NEXT_PUBLIC_ENV === 'production' &&
        <GoogleAnalytics gaId="G-BJKTECJ4DQ" />
      }
    </html>

Initialising Sentry only for Production Environment

if (process.env.NEXT_PUBLIC_ENV === "production") {
  Sentry.init({
    dsn: "",
    tracesSampleRate: 1,
    enableLogs: true,
    debug: false,
  });
}

Using API base URLs based on Environments

const BaseURLs: BaseURLsType = {
    development: {
        api: 'http://127.0.0.1:5001/<project_jd>/<region>/api'
    },
    staging: {
        api: 'https://api-stage.yourdomain.com'
    },
    default: {
        api: 'https://api.yourdomain.com'
    }
}

export const getBaseUrls = () => {
    return BaseURLs?.[process.env.NEXT_PUBLIC_ENV] || BaseURLs.default;
}

Initialising Emulator when developing locally

// point functions to local emulator
if(process.env.NEXT_PUBLIC_ENV === 'development') {
  connectFunctionsEmulator(functions, '127.0.0.1', 5001);
  if (!firebaseAuth.emulatorConfig) {
    connectAuthEmulator(firebaseAuth, 'http://127.0.0.1:9099')
  }
}

Enable Redux dev tools locally

export const makeStore = (preloadedState?: Partial<RootState>) => {
  return configureStore({
    reducer: rootReducer,
    // ... more code
    devTools: process.env.NEXT_PUBLIC_ENV === 'development',
  });
}

Securing Cookies on Production

cookiesInstance.set(SESSION_COOKIE_NAME, uid, {
    httpOnly: true,
    secure: process.env.NEXT_PUBLIC_ENV === 'production',
    maxAge: 60 * 60 * 24, // One day
    path: '/',
});

Managing Environment Variables in Backend Codebase

Managing environment variables in firebase functions codebase is little bit tricky. Passing the environment variables in the build command works only partially, let me explain.

The environment variables that we define for different environments can be used in two different contexts, first is inside the firebase functions, and other is outside the firebase functions, this could be any where in the codebase and depending on where you want to use the variables, you need a different approach to define the variables.

Approach 1: Passing variables in build command

Here is what it looks like to pass the variables in build command —

    "serve": "APP_ENV=development npm run build && APP_ENV=development firebase emulators:start --import ./.db --export-on-exit ./.db",
    "deploy": "APP_ENV=production firebase deploy --only functions --project <prod_project_id>",
    "deploy:stage": "APP_ENV=staging firebase deploy --only functions --project <stage_project_id>",

What happens here is that firebase will inject the environment variables during runtime and their values will only be available inside the firebase function execution, check the code below along with the comments

const functionsConfig = {
  maxInstances: 1,
  cors: process.env.BASE_URL, // will be undefined as its outside the function execution
  timeoutSeconds: 540,
};

exports.api = onCall(functionsConfig, (request: functions.https.CallableRequest) => {
    console.log('APP_ENV', process.env.APP_ENV); // here this variable will be available and will work fine.
}
);

Since we cannot use the environment variables outside the functions, we need a different approach of initialising the variables, and clearly we have a lot or use cases where we need the environment variables outside of firebase functions scope.

Approach 2: Using Firebase aliases, dotenv package and some custom logic

The process.env object is always available during runtime, its just that the variables that we pass during the build command only gets injected in the process.env when a functions starts running. But this environment object does contain other fields for example process.env.FUNCTIONS_EMULATOR and process.env.GCLOUD_PROJECT are accessible and are initiated to the right values and we will be using these variables to correctly initialise the environment variables.

When we want to set multiple environment variables, passing them in the build command can get ugly and unmanageable pretty quickly, therefore its better to rely on some third party package like dotenv to make the variables manageable.

dotenv packages allows us to define variables in environment files and lets us initialise all the variables within that file with a single line. Here is how it works

Step 1 - Define .env.development, .env.staging, .env.production files with the correct values

BASE_URL=http://localhost:3000
APP_ENV=development
GCP_PROJECT_ID=<your_gcp_project_id> // needed to fetch secrets from Google Secrets Manager, you may not need it

You can find your GCP_PROJECT_ID here — https://console.cloud.google.com/welcome

Step 2 - Initialise project aliases in .firebaserc file

This is what .firebaserc looks like

{
  "projects": {
    "default": "<prod-or-stage-project-id>",
    "dev": "stage-project-id",
    "prod": "prod-project-id",
    "stage": "stage-project-id"
  },
  "targets": {},
  "etags": {}
}

Step 3 - Set the correct alias and project id in the build command

    "serve": "firebase use dev && npm run build && firebase emulators:start --import ./.db --export-on-exit ./.db",
    "deploy": "firebase use prod && firebase deploy --only functions --project <prod-project-id>",
    "deploy:stage": "firebase use stage && firebase deploy --only functions --project <stage-project-id>",

Once this is done, and when we run the commands, firebase initialises the process.env.GCLOUD_PROJECT with the correct firebase project id and process.env.FUNCTIONS_EMULATOR boolean to tell if the emulator is running, we will use these two variables to find the environment, here is how we do it in code, and note that the code below must be executed at the very top of the root file of your project, so others can access the environment variables loaded using the dotenv package.

const projectId = process.env.GCLOUD_PROJECT;
const isEmulatorRunning = process.env.FUNCTIONS_EMULATOR === "true";
let env;

if (projectId === "prod-project-id") {
  env = "prod";
} else if (projectId === "stage-project-id" && !isEmulatorRunning) {
  env = "stage";
} else {
  env = "dev";
}

require("dotenv").config({path: `.env.${env}`});

Once, the above code is executed, you can read the environment variables anywhere in your codebase. The code below will now work

// In this code, both the variables -- BASE_URL and APP_ENV will be available with the correct values

const functionsConfig = {
  maxInstances: 1,
  cors: process.env.BASE_URL,
  timeoutSeconds: 540,
};

exports.api = onCall(functionsConfig, (request) => {
    console.log('APP_ENV', process.env.APP_ENV);
});

Let me know if there is another way to achieve this, this is what i have tested and it works just fine for me.

Managing Staging & Production Environments with Firebase

To have a clear, separate and truly independent environments in firebase, we need to create two separate projects from firebase dashboard, one for staging and other for production environment and then we need to setup both the projects identically so that our same codebase can run identically on both the environments.

When we create two separate projects, we will get two separate firebase configs and we need to initialise firebase with the correct config based on the environment. Here is how you can initialise the firebase with the correct config in the frontend code.

const firebaseProdConfig = {
  projectId: "<prod_project_id>",
    // ... other fields
};

const firebaseStageConfig = {
  projectId: "<stage_project_id>",
    // ... other fields
};

const firebaseConfig = process.env.NEXT_PUBLIC_ENV === 'production' ? firebaseProdConfig : firebaseStageConfig;
// Initialize Firebase
export const firebaseApp = !getApps().length ? initializeApp(firebaseConfig) : getApps()[0];

And here is how you can do it your backend codebase

import {initializeApp} from "firebase-admin/app";
import {getFirestore} from "firebase-admin/firestore";
import {applicationDefault} from "firebase-admin/app";

const creds = applicationDefault();

export const FIREBASE_PROD_CONFIG = {
  credential: creds,
  projectId: "firebase-prod-id",
};

export const FIREBASE_STAGE_CONFIG = {
  credential: creds,
  projectId: "firebase-stage-id",
};

export const FIREBASE_CONFIG = process.env.APP_ENV === "production" ? FIREBASE_PROD_CONFIG : FIREBASE_STAGE_CONFIG;

export const firebase = initializeApp(FIREBASE_CONFIG);
export const firebaseDB = getFirestore(firebase);

Securing Environments

When you have deployed the staging and production environments, they need to be secured with the right security rules on cloudflare and firebase both. Your staging environments has no business being publicly accessible and should only be accessible using a VPN.

So, you should setup and custom VPN server on a VPN and setup a cloudflare rule so that only you can access your staging servers and only when you are connected to your VPN.

Here is an video on setting up a custom VPN server, and this is how you setup a cloudflare rule to block public access to your staging frontend and backend URLs.

How to secure your firebase app

Architect — Tue, 10 Feb 2026 03:49:57 +0000

Introduction

This is for all of you building products using firebase as its backend, building a saas app in itself is a huge challenge and once its out in the internet for the world to see, it becomes extremely important to secure it as much as possible, i will try to make this post as concise and precise as possible, let me know if anything doesn’t make sense or seems wrong.

This post will cover most the things that you can do to protect your app from most of the common attacks and help you deal with vulnerabilities that your app may be having, also do notice that some of these guidelines are specific to firebase, but a lot of these are generally applicable to any saas app that has a backend written in some language and deployed on some cloud platform.

Lets begin.

Set max instances

When you are just starting out and launched your saas app using firebase, one thing that you should be aware of is the pay-as-you-go model of firebase’s blaze plan, in this plan, you get charged based on the consumption of resources like functions runtime, or the consumed bandwidth for hosting, now this seems like a good plan as you don’t have to think about server scaling, but it comes with a huge risk of bill spiking in case of burst of traffic, now burst of traffic might be a good thing for you, but this traffic also comes from millions of VPS servers just trying to take any server down through a DDOS attack, and if it ever hits your app with pay-as-you-go model of pricing, your pricing can spike like crazy, so it is always a good decision to set the max instances to 1 or 2 when you are just starting out.

You can set the max instances through two ways, one is through your functions config and second through the firebase dashboard.

This is how you do it from your code

import {onCall} from "firebase-functions/v2/https";
import {APIManager} from "./entities";

const functionsConfig = {
  maxInstances: 1,
  cors: process.env.BASE_URL,
  timeoutSeconds: 540,
};

exports.api = onCall(functionsConfig, APIManager);

And you can find the option to set the max instances from dashboard as well
Head over to https://console.cloud.google.com/run
Select you function
You will find the header containing Scaling options with min and max values

And for your internal api endpoints for your admin dashboards, always set the min instances to 0 and max to 1, setting min instances to 0 will save you a lot of money in the long run.

Configure domains

Although having a domain is not required to build and launch a saas product, but having a domain will help you a many ways, and you can always find a cheap domain name to begin with.

Once you have a domain, make sure to do this —

Head over to https://console.cloud.google.com/run
Select your function
Go to Networking tab
Add you domain under the Custom domains manage button
Once you add a custom domain, it takes a few hours for it to become active, and once its active, you can just use this domain for your api calls instead of using firebase’s subdomain
Once your custom domain is setup, make sure to uncheck the Enable checkbox, this will disable all the google’s sub domains that point to your firebase functions.

Once you have added a custom domain, you have now infinite possibility to control the traffic to you app, you can add custom rules to allow or block certain kind of traffic(more on this later).

Integrate Cloudflare to sit in front of your domain

I am not sure how a service like cloudflare is free in this time, but while it is, lets try to use it as much as possible, also i will try my best to document things that are free and doesn’t charge you upfront while you are starting.

Cloudflare is a proxy, that sits in front of your domain and traffic that comes to your domain must pass through cloudflare first, think of it as a gatekeeper, and you can configure it to allow or block certain kind of traffic.

I won’t go in details about how to setup cloudflare, as there are tons of tutorials out there, here is one by the cloudflare team — https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/

Block cloud service providers

The DDOS attacks are growing at an crazy rate, with the 71% of global bot traffic coming from united states alone using either AWS or GCP, and it is a no brainer at this point to block as much unwanted traffic as possible.

Unless you are hit by a botnet attack(there isn’t much that you can do if it happens), It will be best to block all the traffic coming from virtual servers(VPS), virtual servers are not actual users browsing for your services, but they run code which is intentionally written to sabotage the targeted servers.

IMPORTANT: Traffic coming from VPS is not always bad, and you need to be extra careful when blocking traffic from virtual servers, as this may break critical integrations like Stripe, GoogleBot etc.

To block traffic coming from VPS, we need to know the IP addresses or ASNs(Autonomous System Number) of all those places which can send traffic to your servers in order to block them.

Here is a list of ASNs of the major cloud service providers globally.

Service Provide	ASN
AWS	AS16509
Azure	AS8075
Google Cloud	AS15169, AS396982, AS19527, AS394089, AS139070, AS139190
Oracle Cloud	AS31898, AS401341, AS20054, AS18916, AS54253, AS46558
Alibaba Cloud	AS45102, AS24429, AS134963
IBM Cloud	AS36351, AS46704, AS13749
DigitalOcean	AS14061, AS46652, AS394362, AS200130
Hetzner Cloud	AS24940, AS213230, AS212317, AS215859
Render	AS397273
Salesforce	AS14340, AS393517, AS394808
Linode	AS63949
OVH Cloud	AS16276, AS35540
Tencent Cloud	AS45090, AS132203, AS133478
Vultr / Constant	AS20473
Scaleway	AS12876
UpCloud	AS202053
Contabo	AS51167, AS40021, AS141995
Kamatera	AS36007, AS41436, AS215728, AS64022
GCore	AS199524, AS202422, AS210559, AS59245
Gandi	AS29169, AS203476, AS209453
Exoscale	AS61098
Cloudflare	AS13335
Paperspace	AS394996
LambdaLabs	AS398090
—	—
Netlify	Uses AWS Infra
JFrog	Uses AWS, GCP, Azure Infra
OpenShift	Uses other cloud hosting providers

Here is the cloudflare expression to block all the traffic from above —

(http.host wildcard r"*yourdomain.something*" and ip.src.asnum in {16509 8075 15169 396982 19527 394089 139070 139190 31898 401341 20054 18916 54253 46558 45102 24429 134963 36351 46704 13749 14061 46652 394362 200130 24940 213230 212317 215859 397273 14340 393517 394808 63949 16276 35540 45090 132203 133478 20473 12876 202053 51167 40021 141995 36007 41436 215728 64022 199524 202422 210559 59245 29169 203476 209453 61098 13335 394996 398090 47583 204915 22612 19318 55293 46606 26347 54548 8560 32244 40819 40476})

Whitelist IPs/ASNs for webhooks & important bots

Once you have blocked all the cloud service providers, just make sure to allow the traffic from the ones that are useful and necessary for your product to work, for example —

Stripe webhooks are triggered from AWS servers and are needed so that your product can show the correct subscriptions and invoices to your users
GoogleBot sends traffic from GCP to your web pages so that i can understand and index your content for SEO

So you need to add the allow rules for these cases.

Here is how you can allow traffic on Stripe hooks only from Stripe verified servers, Stripe publishes the list of IPs of there servers here — https://docs.stripe.com/ips#webhook-notifications

And this is what an IP list looks like in cloudflare

Similarly you can also allow GoogleBot traffic from a specific list of IPs

Set rate limit on all the api endpoints

This is also a no brainer, a normal user doesn’t open you pages 1000 times a second, and this is exactly we want to block, so this is very subjective, but observe the traffic pattern and pick 2x the normal traffic from one IP, and set this as rate limit using Cloudflare, here is how you can configure a rate limiting rule. Although one important thing to consider is the networks inside large offices where all the people connected to the same router will have same IP address and if all of them try to access you product, it will immediately block their IP, which is not right, so you might need to think about how you can set the rate limit appropriately.

Setup VPN to access internal dashboards and APIs

The internal dashboards are internal for a reason and there is no need to make them accessible outside of a private network, Setup a VPN server on a cheap VPS and allow traffic to your dashboards only when you are connected to your VPN.

I won’t talk about setting up the VPN server, there are too many online videos and blogs for this, this video is quite good too.

Once you are done with a VPN server, you will have to configure cloudflare to allow traffic to your internal dashboards only when you are connected to the VPN, so how this works is when you connect to your VPN server, all of your requests start going to your VPN server first and then your VPN server forwards this request to the appropriate DNS, but when the requests are sent out from the VPN servers, the source IP address for all those requests becomes that of your VPN server, so here is the flow

You hit https://admin.yourdomain.com
Request is sent to your VPN server
VPN server forwards this request to Cloudflare
Cloudflare forwards this request to the appropriate hosting servers.

While forwarding your requests to the hosting servers, Cloudflare has the option to allow or block this request based on the source IP(in this case your VPN server’s IP address), and this is how we block access to our internal dashboards by only allowing our VPN server’s IP address to pass through. Here is what a cloudflare rule looks like

Don’t use Firestore SDK on client to get data when possible

Don’t get me wrong, but using firestore directly in your frontend javascript code is extremely prone to bugs, errors and privilege escalation, when you are choosing to use firebase client SDK on your frontend code, and you don’t have firebase rules configured properly, you are literally giving everyone unlimited read/write access to you database.

There are two solutions here —

You either configure firebase rules properly with correct read/write access control, properly use custom claims to define what users can do and what they can’t.
You can use firebase functions as your backend layer which will then interact with the database instead of your client interacting with database directly.

Block countries as much as possible

Here are some reasons to block certain countries —

Some countries are automatically blocked by payment providers due to high risk so there is no point in allowing traffic from those countries to your product. For example, Stripe has blocked Cuba, Iran, North Korea, and Syria, and the Crimea, Donetsk, and Luhansk regions due to being high risk jurisdictions.
As per Cloudflare’s report on DDOS attacks, almost half the attacks originated from Brazil and Vietnam, so it may be a good idea to block those countries, but if a majority of your customers belong to these nations, you need to set other measures to handle attacks and frauds.

Here is how you create a cloudflare rule to block countries

Integrate AppCheck

In an ideal scenario, a user opens up the application and then the application loads the content through api calls, but during a DDOS attack, the api calls happens in isolation and in very high volumes, to solve this problem, Google has a feature called Firebase App Check which protects your firebase backends from abuse by preventing unauthorised clients from accessing your backend.

So basically it enforces that only your client app can access your backend, and this way it would be extremely difficult for people to DDOS your backend.

Handle errors and exceptions carefully

The more information available about our backend systems in public, easier it is to hack into it, and one of the ways developers unknowingly expose important information is through error and exception handling

So it is extremely important to handle all the exceptions with try catch statements and only return very minimal error code and messages to clients while sending the error details to Google cloud logs which can easily be accessed from the Google Run dashboard.

Secure payment webhooks

The payment providers talk to your backend through webhooks, which is just a fancy name for an api endpoint, so whenever an event occurs in context of payments, the payment processor(Stripe for example) sends the data to the our backend on the webhook endpoint and webhooks are needed to make the product work as expected.

Even though webhooks are just api endpoints which only expects traffic from our payment processors, they still need to be secured and protected. There are a few ways you and secure your webhook endpoints

First and foremost, only allow traffic from the certain list of IP addresses from where the payment processors events originate, Stripe shares these ip addresses as json files and can be found here — https://docs.stripe.com/ips
The payment processors usually have a verification mechanism as well to verify the requests before processing the events. Make sure to verify the signature before handling events.
Payment processors are also susceptible to session replay attacks, make sure to accept payment events considering their time of generation, refer to this guide from Stripe.

Configure stripe carefully

Enable 3DS for all transactions

With 3DS, customers need to complete an additional authentication step before they can complete the purchase, and this additional authentication guards against stolen card frauds

Card Acceptance Rules

Block if :risk_level: = 'highest'
Block if :risk_score: > 50
Block if CVC verification fails based on risk score
Block if Postal code verification fails based on risk score
Block if payment matches one or more values in default Stripe block lists
Block if :declined_charges_per_customer_hourly: > 2

This article from Stripe has good explanations on rules, when to create, when to use existing.

Block countries

You should block countries which contributes massively to online fraud - reference, here is how you can block a card based on its location and here is a rule to block all the cards from china —

Block if :card_country: = 'CN’

Save secrets securely

Secrets like API keys can easily be exposed to multiple people working on the project, or in case if someone accidentally gains access to the codebase, and this can happen either because of incorrect privileges and code repository visibility settings, either way, it is always good to store your secrets in Google cloud secrets manager and fetch them only in scopes where it is needed.

Another important thing to notice is the pricing, secrets manager charges you based on how many times you fetch a secret, so it will be better so temporarily cache it and set a TTL(time to live) so it automatically gets expired in some time.

Here is how you can fetch it inside nodejs

import { SecretManagerServiceClient } from "@google-cloud/secret-manager";
const client = new SecretManagerServiceClient();

let cachedSecret = {};
const fetchSecret = async (secretKey: string) => {
  const name = `projects/<your_project_id>/secrets/${secretKey}/versions/latest`;
  try {
    const [version] = await client.accessSecretVersion({ name });
    const payload = version?.payload?.data?.toString("utf8");
    if (typeof payload !== "string") throw new Error("Secret not found");

    // Update cache
    cachedSecret = { value: payload, fetchedAt: Date.now() };
    return payload;
  } catch (error) {
    console.error('Failed to fetch secret from secrets manager', {
      name
    });
    return null;
  }
}

const openAIDevKey = await fetchSecret('OPENAI_DEV_KEY');

Setup signup quota within firebase

Now a days it has become extremely easy to write a script that can create accounts in bulk and if you rely on email password based login / signup for your product, it becomes really important to enforce signup limits, firebase allows you to configure this limit from its Authentication settings dashboard.

Setup DMARC records properly

When you send an email from gmail to apple mail, apple mail first verifies that the email is actually coming from gmail and not from some attacker, apple does this by checking DMARC DNS records of gmail.com, and this record tells apple two things —

Who is allowed to send emails from gmail.com
Cryptographic signature of email

DMARC record is a TXT record in DNS and here is what it looks like —

"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;rua=mailto:youremail@gmail.com;"

and here is what the different parameters mean

v=DMARC1 → Version, its mandatory
p=reject → Reject the email completely
sp=reject → Reject emails coming from any of the sub domains of the current domain
aspf=s → this means the to strictly check the sender domain and my domain, no loose checks allowed
rua=mailto:youremail@gmail.com → This mentions the email where aggregate reports will be sent

If you are not using you domain for emails, make sure to set the DMARC TXT record as above, and change the email to yours.

Stay on firebase spark plan for as long as possible

This may not be something you can follow as due to requirements, you may have to upgrade to the blaze plan, the reason is that blaze plan has pay-as-you-go model and this model increases your pricing with usage, which may not be an issue, but spark plan defines the hard limit and once that limit has reached, your app will stop working, which may or may not be fine when you are just testing the waters.

Check observability metrics regularly

As you will market you product, and start receiving traffic, it becomes very important to check the logs consistently, be it your server logs from Google cloud logs, or your frontend or backend error logging from third party tracking tool, or Google analytics, it will give you a near real time updates on what is happening in your product.

These logs also gives you a general idea about the health of your product and whether you need to work on something or not.

Move CPU and cost intensive operations in background through background/cron jobs

This is again a no brainer, if you want to do anything that is CPU intensive or cost intensive, you can create a queue and have your scheduler pick items from the queue for execution, it helps in multiple ways —

First is you are removing the direct trigger of some expensive operation from your client, this also helps in avoiding large operations due to bot attacks
It also improves the user experience and you can re trigger any items from your queue due to failure.
It also avoids the timeout issues that can happen if the operation takes to much time.

HackerOne offensive testing & bug bounty program

It may not be possible to find and fix all the critical issues in your app and this is where you can leverage HackerOne where a large group of hackers and testers test your app for bugs and issues and report them to you for a small amount of money. This way of bug hunting fast tracks the entire process of securing your app.

Use Google Captcha for forms

If you have input fields in you app from where you need to collect data, make sure to integrate some kind of captcha verification, this will help you a lot in reducing the bot triggered form submissions.

Block invalid routes from cloudflare

This may not be something that you need to do immediately and it also increases the maintenance effort for you app, so the ideas is to allow traffic only on those routes which you have explicitly handled in your code, for example —

Web frontend only have these routes — /, /pricing, /about, /terms
Backend only have these routes https://api.domain.com/

Important Note:

Although this rule will save you from unnecessary bot attacks, it takes some effort to find all the routes and generate a regex expression for those routes.
You will also have to include routes that serve the static assets like CSS, JS, manifest and favicon file.

If you are building a saas app and need help with its development, scaling and security & marketing, I have built Architect AI to help the fellow builders so you can build a robust and secure app.