If you are selling software to businesses, your customers are trusting you with their data. This guide explains the data security basics founders should get right before launch: keeping customer data separated, checking permission on every request, protecting logins, handling secrets, verifying webhooks, and planning backups and offboarding. It draws on OWASP's published guidance and Stripe's webhook documentation, and it is written for founders who need to require and explain these controls rather than implement them personally.
Access control failures are not a rare edge case. In OWASP's Top 10 of the most critical risks to web applications, Broken Access Control sits at the very top of the 2025 edition. For a SaaS product the reason is structural: you serve many customers from one system, so a single weakness in how you separate and authorise access can expose every customer's data at once.
That changes who owns the problem: your engineers implement the controls, but you decide whether security is in the plan, the budget, and the acceptance criteria. Treat it as something to add “once we have customers,” and you will answer questionnaires with gaps you can no longer hide.
The defining security challenge of multi-tenant SaaS is separation. This article focuses on the common B2B case: many customers served from one system, each seeing only their own data. Three layers matter, and they reinforce each other.
First, every request should carry a verified customer identity: treat client-supplied identifiers as selectors only, and verify the authenticated user is authorised to act in that customer's account, as OWASP's multi-tenant guidance recommends. Customer identity must come from your server-side session or token, not from the request itself.
Second, enforce separation at the data layer, not only in application code. The options range from separate databases per customer, to separate schemas, to row-level controls where the database itself filters rows by customer. Row-level security is one such option — but only when the policies are correct, the tenant context is verified, and the application connects with a non-bypassing, least-privileged role.
Third, apply the same separation around the database: include the customer identifier in cache keys, keep uploaded files under customer-scoped paths with access authorised before serving, and carry verified customer context in queues and background jobs.
Finally, test the separation the way an attacker would: automated checks that attempt to reach one customer's records while authenticated as another, run against the real deployment path.
Login answers one question: who is making this request. Every sensitive request then needs a second: may this user perform this action on this record? OWASP's API Security Top 10 lists Broken Object Level Authorization as its number-one risk — without per-object ownership checks, changing an identifier in a request can reach another customer's data.
Imagine a reporting page that loads an invoice by its identifier. If the server checks only that the user is logged in and never confirms the invoice belongs to the user's company, a substituted identifier can reach someone else's invoice — a purely illustrative example of a common pattern. Every endpoint must confirm, on the server, that the record belongs to the caller's customer. Membership is only the first half: belonging to the same account does not authorise every operation — users still need per-action permissions within the customer's data.
Privileged paths deserve extra care: administrative functions that can see across customers should be explicit, separately authorised, and auditable. And when access is denied, keep responses generic — distinguishing “this record does not exist” from “this record exists but is not yours” leaks information about other customers' data.
Start with passwords. Length matters more than complexity: under eight characters is weak with multi-factor authentication enabled, under fifteen without it — per OWASP's authentication guidance, which follows the NIST password standard. Drop composition rules and forced periodic changes, screen new passwords against common and breached lists, and hash them with a dedicated password-hashing function — never plain text.
Multi-factor authentication materially raises the bar: even with a stolen password, the second factor still stands in the way. OWASP recommends offering it to all users and requiring it for administrative accounts. Also plan the recovery path: regaining access after a lost second factor must not become a back door.
Two fundamentals sit underneath. Transmit credentials only over HTTPS/TLS — OWASP's authentication guidance requires it for login and every authenticated page. And protect the login endpoint against automated guessing: OWASP describes login throttling and account lockout as the standard protections after repeated failures.
Two smaller controls complete the picture: generic login-failure messages, and re-authentication for sensitive actions like changing an email address or payment details.
API keys, database passwords, signing secrets, and tokens leak through ordinary channels: source control, chat, shared documents. Keep secrets in environment variables or a secrets manager — never in repositories — and rotate immediately if you suspect a leak.
Scope each credential to the minimum permissions for its job, so one compromised key does limited damage.
Modern SaaS products react to the outside world — a payment provider reporting a charge, a customer platform sending an update. These arrive as webhooks, and they must be verified, because your webhook URL is effectively public.
For Stripe specifically, use Stripe's official verification for your stack: pass the raw request body, the signature header, and your endpoint's signing secret to the library, which also rejects signatures whose timestamps are too old. Do not hand-roll this check, and work from the raw body: a body the framework has already parsed and re-serialised has different bytes, breaking the signature.
Then build handlers that assume an unreliable world, handling two problems separately. Duplicates: providers retry failed deliveries — Stripe retries for up to three days in live mode — so make handlers idempotent. Ordering: events can arrive out of sequence, so a late event must not overwrite newer state; tracking event identifiers detects duplicates but does not establish order. Apply the same suspicion to data you pull from third-party APIs — OWASP lists unsafe consumption of APIs among its top risks — and validate it the same way.
Backups are only real once restored — schedule regular restore tests. Restore the shared backup into a restricted, isolated environment, extract the target customer's data, and verify the selective recovery does not expose or overwrite another customer's records.
Offboarding needs the same discipline: when a customer cancels, your retention and deletion policy should cover every place their data lives — database, caches, file storage, exports, backups. Revoke sessions and API keys promptly, keep an audit trail of provisioning and deprovisioning, and provide data export where the contract requires it.
One related habit: never log sensitive customer data in plain text. Logs get copied into dashboards, error trackers, and support threads, where they may be visible to people who should not see customer data.
When something goes wrong — or a customer asks — you need records saying who did what, when, and to which customer's data. Carry verified customer and user context in audit events, and alert on denied or unexpected cross-customer access attempts. A centralised audit store is fine when read access itself enforces customer scope. A customer asking about your audit logging is really asking: if something happens to our data, will you know, and will you tell us?
Not everything belongs in the first release. Whether you need a SOC 2 report, independent penetration testing, or a dedicated security function depends on your data sensitivity, exposure, customer requirements, and contractual commitments. Note the distinction: a SOC 2 report is an independent examination of your controls, not a certification of your product — and it can only attest to controls you have actually built.
Independent testing should not wait until the company grows: the more sensitive the data, the stronger the case for testing early. What cannot wait is honesty — never claim controls you have not built, and never present the basics above as complete enterprise security.
Turn this guide into a review: ask your team or development partner to walk through each section and show, not tell — passing tenant separation tests, working webhook verification, a performed restore, a denied cross-customer attempt in the audit log.
For founders still scoping the build, the project cost calculator estimates budget and timeline from scope and complexity — security and compliance needs are among its listed cost drivers — and the earlier guide to SaaS development planning covers the product decisions that shape these controls. Multi-tenant architecture and data separation are part of iCodeLTD's SaaS development service; discuss your requirements through the contact page.
Whether you need a SOC 2 report depends on your data sensitivity, customer requirements, and contractual commitments. A SOC 2 report is an independent examination of your controls, not a certification. Build the underlying controls from day one, so that if an examination comes, it attests to what you already do.
It helps with one part: login. A managed provider covers password handling, multi-factor authentication, and session management — but only the parts you configure and verify. It does not separate your customers' data, authorise per-request access, scope your secrets, verify your webhooks, back up your data, or keep your audit trail.
Write down, in plain language, what you actually do for each control it asks about, and point to evidence: tenant separation tests, backup restore records, your access review process. Where you have a gap, say so and say what your plan is. Questionnaires are scored, but they are also read by people.
AI Solutions
Is Your AI Feature Actually Working? How to Measure AI Performance After Launch
Your AI feature impressed in the demo. Here is how founders define what “working” means and measure it continuously against real usage.
Read moreProduct Delivery
Fixed Price vs Time and Materials: A Founder's Guide to Software Pricing Models
Fixed price or time and materials? Learn how each software pricing model assigns risk, when each one fits a startup project, and what your contract must include either way.
Read moreSaaS Development
How Much Does It Cost to Build a SaaS App in 2026?
SaaS app development cost guide: iCodeLTD projects start from $5,000, with lean MVPs often $5,000–$15,000. Timelines, rates, and cost drivers.
Read moreReady to review scope for AI, SaaS, web, mobile, or automation work?
