The multi-tenant mistake that loses SaaS enterprise deals

Almost every SaaS product stores many customers in one database. That is normal and sensible. The risk is the day one customer sees another customer’s data. It usually happens through a single forgotten line of code, and it is the kind of incident that ends enterprise deals before they start.

How leaks actually happen

• A new report or export written in a hurry that forgets to filter by customer.
• An API endpoint that takes a record ID and returns it without checking who is asking.
• A background job or cache shared between customers, so one customer’s results get served to the next.
• Search indexes, file storage and analytics copies that were never separated at all.
• Support tools that let staff jump between customers, with no record of who looked at what.

Notice that none of these are clever attacks. They are ordinary features built by someone who was thinking about the feature, not the separation.

Enforce it in one place

The rule we follow: no developer should have to remember to filter by customer. If separation depends on every query being written correctly, it will eventually fail. Instead it is enforced once, underneath everything.

• In the database, using row-level security in PostgreSQL, so even a careless query only sees the current customer’s rows.
• Or in the application framework, with a global scope that applies the customer filter to every query automatically, such as Laravel’s global scopes.
• File storage, caches and search indexes keyed by customer as well, not just the main tables.
• An automated test suite that logs in as customer A and tries to read, change and export customer B’s data, every endpoint, on every build.

What enterprise buyers will ask

Larger customers send security questionnaires, and the same questions come up every time. It is far cheaper to design for them than to retrofit:

• How is our data kept separate from your other customers?
• Can we sign in with our own identity provider (single sign-on)?
• Is there an audit log of who accessed our data, including your staff?
• Where is our data stored, and can it stay in a particular country?
• Can we export everything, and can you delete everything when we leave?
• When was your last penetration test, and can we see the summary?

If you already have the problem

Many early SaaS products filter by customer in the code, one query at a time. That is fixable without a rewrite. We map every place data is read, add the separation underneath, then run the cross-customer tests until they come back clean. It is usually weeks of work, and much less than a lost deal or a breach notification.