SaaS Security Checklist for Multi-Tenant Apps

SaaS security begins with tenant boundaries and continues through every request, query, cache key, file path, background job, export, log, backup, and support action. Authentication alone is not enough. A signed-in user may still access the wrong company if resource ownership is not checked consistently.

This checklist is a practical engineering baseline, not a security certification or substitute for threat modelling, professional testing, legal review, or incident planning appropriate to the product and data.

1. Define the tenant boundary

Decide what a tenant represents: company, school, clinic, franchise, or customer account. Document user membership, invitations, company switching, suspended tenants, support access, and offboarding.

• derive tenant context from authenticated, verified server-side identity;
• never trust a tenant ID supplied only by URL, header, form, or browser storage;
• include tenant scope in database queries, cache keys, object storage paths, queues, and logs;
• reject cross-tenant object references even when IDs are valid;
• test two seeded tenants against every sensitive endpoint;
• define whether platform admins can cross boundaries and how access is approved/audited.

OWASP's Multi-Tenant Security Cheat Sheet recommends validating tenant ownership at the data-access layer and avoiding shared cache or resource lookup without tenant context.

2. Authentication

• use established password hashing through a maintained framework;
• require verified email/phone only where the workflow needs it;
• protect signup, login, password reset, and verification from abuse;
• use generic recovery responses that do not expose account existence;
• expire reset tokens and invalidate them after use;
• offer MFA for privileged roles and high-risk products;
• prevent default or shared administrator accounts;
• alert on suspicious login/reset patterns;
• document identity-provider and social-login account linking.

Do not build custom cryptography or token formats without specialist need and review.

3. Authorization

Authorization must run on every request. Use capability, tenant/branch scope, record ownership, and state. Admin should not become a bypass around all data policy.

Examples:

• user can view assigned leads in their tenant;
• manager can approve branch discounts within threshold;
• accounts user can allocate payment but cannot delete posted receipt;
• tenant owner can invite members but cannot access another tenant;
• platform support can use time-limited, reasoned access;
• export and bulk actions require separate permission.

OWASP's Authorization Cheat Sheet recommends least privilege, deny by default, permission checks on every request, appropriate logging, and authorization tests. Use the permission matrix template to turn requirements into test cases.

4. Session and token security

• use secure, HttpOnly, appropriate SameSite cookies when cookies are the design;
• rotate sessions after login or privilege change;
• set inactivity and absolute expiry based on risk;
• revoke sessions after password reset, account suspension, or sensitive change;
• protect state-changing requests from CSRF under the chosen architecture;
• do not place long-lived secrets in local storage;
• validate token issuer, audience, expiry, signature, and intended use;
• support logout from current and all devices where appropriate.

Document what happens when a user's tenant membership is removed while a session is active.

5. Database and query controls

Database row-level security, separate schemas, or separate databases can add defence in depth depending on architecture. None removes the need for application-level policy and tests.

6. Secrets and environment configuration

• keep production secrets outside source control and client bundles;
• separate development, staging, and production credentials;
• rotate leaked, departed-user, or provider-compromised keys;
• grant minimum provider permissions;
• avoid printing secrets or full tokens in logs;
• inventory secrets with owner and renewal/rotation procedure;
• protect build and deployment environments;
• use webhook secrets and validate provider authenticity.

Scanning a repository helps, but review deployment history, CI logs, backups, and copied environment files too.

7. File uploads and downloads

• allow only required file types and sizes;
• validate content, not extension alone;
• generate safe storage names;
• keep private files outside public web roots;
• authorise every download against tenant and user scope;
• use short-lived signed links where appropriate;
• scan or isolate risky uploads under the product threat model;
• strip unsafe metadata when required;
• define retention and deletion;
• prevent SVG/HTML or document content from executing in the app context.

A public predictable PDF URL can bypass otherwise strong dashboard security.

8. API, webhook, and background-job safety

• validate input with explicit schemas;
• rate-limit sensitive and expensive endpoints;
• use idempotency for payment, invoice, and message events;
• verify webhook signatures/authenticity and timestamp policy;
• handle duplicate and out-of-order callbacks;
• scope queue payloads and workers by tenant;
• avoid placing sensitive data in job names or error logs;
• expose failed jobs to authorised operators;
• separate user errors from internal diagnostics;
• version APIs and integration contracts.

The webhook integration guide covers retry and reconciliation patterns.

9. Browser and application protections

• enforce HTTPS and secure redirect/canonical policy;
• use a reviewed Content Security Policy where compatible;
• encode output and sanitise permitted rich content;
• protect against XSS, injection, CSRF, SSRF, and insecure direct object access under the architecture;
• set safe security headers;
• keep dependencies and runtime supported;
• remove debug endpoints and test credentials;
• restrict CORS to required origins and methods;
• avoid exposing internal stack traces.

Security headers help but cannot compensate for missing authorization or unsafe queries.

10. Logging and audit

Security logs should capture authentication events, permission failures, tenant switches, privileged changes, sensitive exports, support access, webhook failures, and configuration changes. Include actor, tenant, action, time, result, and request correlation without logging passwords, tokens, full payment data, or unnecessary personal information.

Protect logs from unauthorised alteration and access. Define retention, alert rules, and an owner who actually reviews high-risk events. The audit log guide distinguishes operational activity from accountable change history.

11. Backups and recovery

• encrypt backups according to risk and architecture;
• keep access separate from ordinary application users;
• define frequency, retention, region, and owner;
• test restoration into an isolated environment;
• verify tenant-level and full-system recovery needs;
• include file/object storage and configuration, not database only;
• document recovery time and data-loss objectives;
• protect and rotate backup credentials;
• include provider outage and accidental deletion scenarios.

A backup that has never restored is an assumption, not a recovery capability.

12. Deployment and supply chain

• protect the main branch and deployment credentials;
• require review for security-sensitive changes;
• pin and review dependencies under project policy;
• generate and inspect vulnerability reports;
• separate build permissions from production data access;
• sign or verify artefacts where the delivery model supports it;
• keep staging from using copied production personal data;
• maintain rollback and database-migration procedures;
• monitor deployment health and errors.

13. Security testing

Test behaviour, not only scanner output:

1. unauthenticated access to private endpoints;
2. low role calling admin actions directly;
3. Tenant B reading/updating Tenant A IDs;
4. branch user changing branch/company references;
5. expired/revoked session access;
6. export/download authorization;
7. webhook replay and duplicate delivery;
8. upload/download abuse cases;
9. password-reset account enumeration;
10. backup restore and incident drill.

OWASP's Authorization Regression Testing Cheat Sheet specifically describes cross-tenant and role-demotion tests. Add these to automated regression coverage and schedule independent assessment based on risk.

14. Incident and offboarding readiness

Define who receives alerts, how access is contained, how evidence is preserved, how customers are informed under applicable obligations, and who approves recovery. Keep emergency contacts and provider procedures outside the unavailable production system.

Tenant offboarding should cover access termination, export, deletion/retention, backups, API keys, custom domains, webhooks, and confirmation. Do not retain data indefinitely by default.

Release checklist

• [ ] tenant identity and support-access model are documented;
• [ ] authentication and recovery abuse controls are tested;
• [ ] authorization is deny-by-default and server-enforced;
• [ ] cross-tenant tests cover API, files, search, export, cache, and jobs;
• [ ] sessions and privilege changes revoke correctly;
• [ ] secrets, webhooks, uploads, and downloads follow policy;
• [ ] security logs avoid sensitive payloads and generate useful alerts;
• [ ] backup restore and deployment rollback are rehearsed;
• [ ] dependencies and environments have named owners;
• [ ] incident and tenant-offboarding procedures are accessible.

VASUYASHII security approach

VASUYASHII treats tenant scope, backend permission checks, auditability, backup restore, and failure handling as design requirements rather than post-launch add-ons. Our implementation review uses two seeded tenants and attempts cross-tenant reads, writes, searches, exports, files, cache hits, and background jobs through direct API requests. The expected result is explicit denial without leaking whether the other tenant's record exists.

This is an engineering approach, not certification or proof that a specific application is secure. Review software development, web applications, or contact us for a scoped security review.

FAQs

Is RBAC enough for SaaS security?

Not always. Roles may need tenant, branch, ownership, relationship, and record-state attributes. A simple role name can become difficult to manage as exceptions grow.

Should every SaaS app use separate databases per tenant?

No universal architecture fits all products. Shared tables, schemas, or databases have different isolation, cost, operations, and recovery tradeoffs. Choose through threat modelling and enforce/test tenant scope regardless.

Does MFA make the app secure?

MFA reduces account-takeover risk but does not fix broken authorization, cross-tenant queries, exposed files, unsafe webhooks, or vulnerable dependencies.

How often should security testing happen?

Run automated checks continuously and focused manual/independent assessment according to product risk, major architecture changes, new sensitive workflows, and compliance obligations.

Can support staff access customer tenants?

Only under a documented model with minimum permissions, business justification, time limits, approval where appropriate, visible audit, and customer expectations.

What should a small SaaS team fix first?

Tenant isolation, authentication/recovery, server-side authorization, secrets, private files, backups, monitoring, and repeatable security tests provide a practical initial baseline.

Next step

Use the SaaS authentication and tenant-isolation guide to turn this checklist into testable identity, data-scope, recovery, and incident controls.

Seed two test tenants and attempt every read, write, export, file, cache, and background-job path across the boundary. Record failures as release blockers. Contact VASUYASHII for a focused SaaS security scope.