How to Secure a SaaS App: Complete Security Guide

Quick answer: Protect tenant data through an explicit isolation model, authenticated and authorized operations, and appropriate resource limits. Review secret handling, browser protections, billing flows, and operational controls. This guide organizes technical checks; production readiness and legal obligations need assessment for your actual service.

By Paula C · Kraftwire Software

Define which users and services may access each tenant’s data, then enforce that policy across the database, application, caches, and background jobs. Use authentication, authorization, validation, and resource controls appropriate to the service. No single database feature or header establishes complete SaaS security.

SaaS security is no longer just about firewalls; it is about protecting the integrity of shared infrastructure.

Use this guide to organize checks and investigate findings whether you build with Windsurf, Cursor, Lovable, or another workflow.

1. Multi-Tenant Data Isolation

In a multi-tenant app, enforce the intended separation between organizations and any explicitly authorized sharing. Test cross-tenant requests and privileged operations rather than assuming that a tenant identifier alone enforces isolation.

Row-Level Security (RLS)

Separate databases, separate schemas, and shared tables are different isolation designs with operational tradeoffs. Postgres RLS can enforce row predicates for roles subject to it; it does not remove the need to review grants, bypass roles, and application permissions. A tenant_id column alone is not a control. Application queries using WHERE filters must derive tenant scope from trusted authorization context.

The following fragment assumes Supabase’s auth helper, an existing text organization_id column, and a verified JWT with an org_id claim controlled by trusted authorization logic. It is a SELECT-only illustration, not a complete migration or tenant model. Check claim freshness, grants, existing policies, and bypass roles; write operations need their own policy review. Standard PostgreSQL does not provide the Supabase auth helper by default.

A correctly scoped policy can restrict selected rows for roles subject to RLS. It does not prevent every IDOR path: an endpoint accepting ?id=123 must still enforce the intended authorization, and privileged database access may bypass RLS. See RLS policies explained.

Isolation Checks

• Privileged access: Restrict and audit roles that can bypass normal tenant policies.
• Search: Enforce tenant permissions in search operations; a tenant_id filter must come from trusted authorization context.
• Caching: Scope cache access to the intended tenant and user. A key prefix such as tenant1:user:profile helps namespacing but is not an authorization check by itself.

2. Authentication and Identity Management

Authentication is the front door of your SaaS.

Identity Controls

• Email verification: Verify mailbox control when the workflow relies on it, including account linking and recovery. It does not prove a person’s identity or stop every form of account abuse.
• MFA: Choose factors and recovery controls for the risk involved, and consider phishing-resistant options for sensitive access. See the security checklist.
• Password checks: Where passwords are used, screen against known compromised values using an appropriate service. The password-strength tool estimates strength; it does not establish that a password has never leaked.

Enterprise SSO

Determine whether customers require SAML or OIDC integration with their identity provider. Use a maintained implementation and test tenant mapping, role assignment, account linking, and access removal. SSO availability alone does not establish correct authorization.

3. API Security and Rate Limiting

Review API operations for authorization, returned data, and resource cost. Include background jobs and integrations in the same permission model.

Rate Limiting Strategies

Implement rate limiting at multiple levels:

IP-Based

Use IP limits where useful, accounting for shared networks and trusted proxies. They do not prevent every DDoS or password-guessing attack.

User-Based

Limit authenticated usage according to the operation’s cost and intended access. A per-user limit cannot replace authorization or prevent all scraping.

Endpoint-Specific

Tune controls for /api/auth/login and /api/billing/checkout, including abuse and lockout risks. Regardless of identifier format, requests for a resource such as user/123 need authorization.

Input Validation And Output Handling

Validate untrusted operations on the backend with schemas appropriate to the data and workflow.

• XSS: Prefer safe text rendering. If HTML is required, use appropriate maintained sanitization for the intended markup and runtime. See XSS prevention.
• CSRF: Apply CSRF defenses to relevant browser flows. Cookie attributes and tokens must match the session design; not every API uses cookie-based authentication. See CSRF guidance.

4. Securing Billing and Webhooks

Billing is a high-stakes area where a single logic error can lead to revenue loss or data exposure.

• Server-side decisions: Map a client’s requested plan to server-approved products, prices, and permissions. Do not trust a client-supplied amount.
• Webhook verification: Verify provider signatures using the required payload and secret, and handle replay, duplicate events, ordering, and account mapping. See webhook verification.
• Audit records: Keep appropriate event, account, and outcome records with access controls and retention. Do not require an end-user IP or actor ID for every provider-generated billing event.

5. Encryption and Data Protection

Data must be protected both while moving across the internet and while sitting on your disks.

Use the SSL checker to inspect supported TLS and certificate signals; review the rest of the data path separately.

• At rest: Choose storage and field-level encryption according to the threat model, including key management and recovery. Application-level encryption is not automatically better for every field or access pattern.
• Secrets: Keep private credentials out of source and browser output. SimplyScan can flag recognized secret patterns in fetched resources, but absence of a finding does not establish absence of a secret.

6. Performance and Security Monitoring

Review connection limits, timeouts, request sizes, and expensive operations for the actual server architecture. Slow-client and resource-exhaustion risks depend on how requests consume capacity; slowness alone is not proof of an attack.

• Availability: Uptime monitoring can alert after checks detect a failure, subject to intervals, thresholds, and delivery.
• Browser policy: Configure Content-Security-Policy for the app’s resource needs. The CSP generator can create a starting policy that still needs testing.
• Discoverability: Answer Engine Optimization concerns public content and crawlability; it does not verify security features or guarantee how an AI system interprets them.

7. Compliance and Auditing

Determine the obligations and assurance requirements that actually apply:

• GDPR: Assess establishment, processing, and territorial scope; citizenship alone is not the test. See the EDPB territorial-scope guidance.
• SOC 2: An examination of controls against applicable trust services criteria within a defined scope, not a blanket security certification. See AICPA’s SOC resources.
• HIPAA: Applies to covered entities and business associates under the relevant rules, not every app containing US health information. See HHS guidance.

Document applicable requirements and control ownership, then retain evidence of operation. Plan any formal assessment with its defined scope and responsible reviewers.

Database

Have you tested tenant isolation, including grants, policies, privileged paths, caches, and background jobs?

Auth

Do authentication, account recovery, and MFA controls match the risk and intended identity workflow?

Headers

Are X-Frame-Options and Content-Security-Policy configured appropriately for the intended embedding and resource behavior? Inspect returned signals with the security headers tool, then test browser behavior.

API

Do authorization and resource limits cover the relevant API operations?

Secrets

Are secret values from .env and other configuration sources kept out of browser-delivered output?

Monitoring

Is there an uptime status page for transparency?

Secure Your SaaS with SimplyScan

Use the security audit checklist to organize review. SimplyScan reports across 8 dimensions and provides supported automated findings; it does not replace a complete application assessment.

For apps built with Bolt.new, Replit, Xano, or other tools, URL checks can inspect recognized secrets, returned headers, and selected backend exposure signals. Free results expose selected findings with usage limits. Run a scan, then test private permissions and workflows outside its coverage.

Browser Header Review

• Content-Security-Policy restricts supported browser behavior according to its directives; safe output handling remains necessary.
• Strict-Transport-Security requires HTTPS for its configured scope in supporting browsers after receipt over HTTPS or through preloading.
• X-Content-Type-Options: nosniff restricts relevant MIME sniffing behavior.
• X-Frame-Options: DENY blocks framing in supporting browsers, so use it only when the app should not be embedded; review CSP framing controls as well.

The security headers tool inspects returned signals. It does not prove complete XSS or clickjacking protection.

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.

13% of the 119 live sites SimplyScan has scanned (15 sites) have at least one high-severity web-security issue, such as a missing Content-Security-Policy or HSTS header.