Common security mistakes in custom SaaS products

Custom SaaS products fail in remarkably similar ways. The mistakes below aren’t exotic. They’re the everyday gaps that appear when a product grows faster than its security foundations. The good news: each is preventable with a clear pattern.

1. Weak tenant isolation

In multi‑tenant SaaS, the single most dangerous bug is one tenant being able to read or modify another tenant’s data. This usually happens when queries filter by an object ID but forget to also scope by the tenant (organisation/account) the current user belongs to.

Fix: make tenant scoping a non‑optional part of data access, for example, a shared query layer that always applies the tenant filter, plus tests that try to access another tenant’s records and expect failure.

2. Treating authorization as an afterthought

Authentication (who you are) gets attention; authorization (what you’re allowed to do) often doesn’t. Teams sprinkle role checks inconsistently, or enforce them only in the UI.

Fix: centralise authorization, enforce it on the server for every request, default to deny, and grant least privilege. The UI hiding a button is not access control.

3. Insecure direct object references (IDOR) in APIs

If GET /api/invoices/1043 returns an invoice without checking that it belongs to the requesting user’s account, anyone can enumerate IDs and read other customers’ data. This is one of the most common and most damaging API issues.

Fix: always verify object ownership against the authenticated principal; consider non‑sequential identifiers as defence in depth (not as the only control).

4. Leaked secrets and over‑privileged keys

API keys committed to repositories, secrets bundled into client‑side JavaScript, or one all‑powerful key used everywhere. Once leaked, an over‑privileged key is a master key.

Fix: keep secrets out of source control and client bundles, scope keys to least privilege, rotate them, and scan your repo and build output for accidental exposure.

5. No rate limiting or abuse protection

Login, password reset, invitation and search endpoints without limits invite credential stuffing, enumeration and denial‑of‑service.

Fix: add rate limiting and backoff on sensitive endpoints, throttle expensive operations, and monitor for unusual patterns.

6. Insecure defaults

Verbose error messages in production, debug endpoints left enabled, overly permissive CORS, or new accounts created with elevated privileges.

Fix: ship secure defaults: minimal error detail to users, debug off in production, narrow CORS, least‑privilege roles for new users.

Sources

Editorial note. Written by the Qaisi team and reviewed by our engineering practice for technical accuracy. Examples are illustrative; your mitigations should fit your architecture. A named reviewer will be shown here once our editorial policy is published.