Multi-Tenant SaaS Security: What the Flowise Flaw Teaches Builders

Multi-tenant SaaS security is not solved when a user can sign in safely. The harder and more consequential question is whether that authenticated user can ever cross the customer boundary and read, change, trigger, export, or infer another tenant’s resources.

A 2025 Flowise Cloud vulnerability offers an unusually clear case study. An attacker did not need to steal an administrator password or defeat a login system. According to the published advisory, an authenticated free-tier user could use a Custom JavaScript Function feature to access environment variables belonging to other tenants. The advisory says researchers enumerated 514 variable names, including names associated with OpenAI, AWS, Supabase, Google, Slack, and email credentials. The issue, CVE-2025-59434, received a CVSS 3.1 score of 9.6, rated Critical. (github.com)

For founders, developers, marketers shipping product-led tools, and teams building AI workflows, the lesson is bigger than one vendor or one JavaScript endpoint: authentication establishes identity; tenant isolation establishes safety. If your app gets those concepts mixed up, a perfectly functioning login can become the first step of a cross-customer breach.

Why authentication is not a customer boundary

Authentication answers a narrow question: Who is making this request? A valid session, passwordless link, OAuth token, service credential, or API key may answer it well.

Authorization answers a different question: Is this identity allowed to perform this action on this specific resource, under the current tenant and relationship context? Tenant isolation adds an even stricter rule: Can this customer’s identity reach only this customer’s data, secrets, files, jobs, configurations, and integrations?

Those distinctions sound elementary, but multi-tenant products create many places for them to drift apart. A backend may correctly verify a signed session token, then fetch an object with a globally unique ID without proving that the object belongs to the session’s organization. A worker may accept a job created by Tenant A, then execute it with platform-wide credentials. A cache may return an object stored under a key that omits tenant context.

OWASP explicitly separates authorization from authentication and recommends validating permissions on every request, denying by default, and testing authorization logic with unit and integration tests. Its multi-tenant guidance makes the same point at architectural scale: shared infrastructure is operationally efficient, but a single isolation failure can expose data across tenants. (cheatsheetseries.owasp.org)

For SaaS teams, the useful mental model is this:

• Authentication is the front door. It determines whether someone gets into the application.
• Authorization is the room key. It determines which actions and records that person may access.
• Tenant isolation is the building’s firebreak. It prevents a mistake, compromised account, feature bug, or internal service from spreading from one customer environment to another.

If a user is legitimately logged in, the front door has done its job. That does not mean the room key, the storage cabinet, the billing account, the background queue, or the admin export function is safe.

The Flowise incident: a cross-tenant problem after login

The Reddit post that prompted this discussion distilled the incident into a question many SaaS teams should ask during design reviews: what if a customer logs in normally and can still see another customer’s data?

The official Flowise security advisory describes an authenticated vulnerability in cloud-hosted Flowise before its August 2025 patch. The affected functionality was the Custom JavaScript Function node, exposed through the POST /api/v1/node-custom-function endpoint. In that execution context, a $vars object intended to represent the current workspace’s environment variables reportedly included variables from other tenants as well. (github.com)

Why the reported impact was so severe

Environment variable names may appear less dangerous than values, but they are an intelligence map of a SaaS platform. They can reveal which providers customers use, which services are integrated, what kinds of credentials may exist, and which attack paths are worth pursuing. In the Flowise case, the published advisory also described the ability to retrieve specific variable values, not just enumerate names.

That matters because environment variables often hold high-value machine credentials, such as:

• LLM and AI-provider API keys
• cloud access keys and database connection strings
• OAuth client secrets and refresh tokens
• service-role tokens for backend platforms
• email, Slack, analytics, or payment-provider credentials
• signing secrets used by application services

A leak in this category can create immediate costs through API abuse, but the larger risk is downstream compromise. A stolen LLM key may generate unexpected usage bills. A cloud credential could expose storage or compute resources. A database URI could make customer records available. A token with broad permissions might allow an attacker to move laterally into systems that are not part of the original SaaS product.

The CVSS vector published for CVE-2025-59434 reflects that chain of consequences: network reachable, low complexity, low privileges required, no user interaction, changed scope, and high confidentiality and integrity impact. The availability impact was scored as none, but a system does not need to go offline for an incident to become existential for a young SaaS business. (app.opencve.io)

The important nuance: this was not an authentication bypass

Calling every SaaS incident an “auth bug” makes it harder to fix the right thing. In this example, the required condition was authenticated access. The security boundary failed after identity had already been established.

That distinction changes what your engineers should review. The question is not merely whether tokens expire, passwords are hashed, or OAuth callbacks validate state. It is whether every capability available to an authenticated account carries—and enforces—the correct tenant scope from entry point to database, cache, queue, function runtime, audit log, and external integration.

Why custom code and AI workflow features raise the stakes

The Flowise example is especially relevant to the current generation of AI products because many platforms deliberately give customers programmable surfaces. They offer JavaScript functions, Python notebooks, SQL blocks, low-code workflow nodes, webhooks, prompt templates, connector configuration, tool calling, code interpreters, and agent actions.

Those features are useful because they let users adapt a product without waiting for the vendor’s roadmap. They are risky because they move untrusted or customer-controlled logic closer to privileged runtime context.

Convenience features often bridge trust zones

A Custom JavaScript Function feature may seem like a harmless extensibility layer. In practice, it sits at the intersection of several sensitive systems:

1. User-controlled input: customers provide code or expressions.
2. Application execution: the platform runs that input somewhere.
3. Secrets injection: the runtime may need provider keys, database access, or configuration.
4. Tenant context: the platform should expose only the current tenant’s resources.
5. Observability: logs, traces, error handlers, and debugging tools may capture inputs and outputs.

A mistake at any one point can become a cross-tenant flaw. The runtime might expose a global environment object. A debug endpoint might dump configuration. A reusable sandbox might retain state. A function executor might run with a platform identity rather than a tenant-scoped one. A connector catalog may correctly hide integrations in the UI but leave their IDs retrievable through an API.

The relevant design principle is not “never allow custom code.” It is: customer-controlled code should receive a deliberately constructed capability set, never ambient platform authority.

That means the runtime should get only the explicit inputs and narrowly scoped short-lived credentials needed for one action. It should not inherit the host process environment, a broad cloud role, a global database connection, or a shared object containing every workspace’s configuration.

AI products have a larger secret footprint

Traditional SaaS products may hold a database password, payment token, and email API credential. AI workflow products often add multiple model-provider keys, vector database credentials, retrieval connectors, model gateways, tool tokens, cloud storage access, evaluation datasets, and agent execution permissions.

More integrations mean more possible secrets. More secrets mean a wider blast radius when isolation fails. It also means customers may unknowingly place regulated data, proprietary prompts, internal documents, and production API credentials in a workspace that appears isolated but is not rigorously enforced.

That is why security reviews for AI features should treat prompt execution, code nodes, MCP connectors, retrieval pipelines, and agent tool access as authorization surfaces—not merely product features.

Multi-tenant SaaS security starts with an explicit isolation model

“Multi-tenant” is not one architecture. A product can share an application process, a database, schemas, tables, caches, message brokers, object storage, search indexes, and worker pools while isolating customers at different layers. Each choice changes the failure modes.

The key is to decide where tenant boundaries are enforced and then avoid relying on only one layer.

Common isolation patterns

Shared database, shared tables. Every row includes a tenant_id, and every query must filter by it. This is cost-efficient and common, but it is vulnerable to missing filters, unsafe joins, bulk exports, and developer shortcuts.

Shared database, separate schemas. Each tenant has its own schema. This can reduce accidental query mixing, but schema selection, migrations, connection pooling, and administrative tools still need strict controls.

Separate databases per tenant. This provides a stronger data boundary and can help with enterprise requirements, though it increases operational complexity, migration overhead, and cost.

Hybrid or tiered isolation. Most customers may use pooled storage, while highly regulated or large customers get dedicated databases, storage buckets, encryption keys, or runtime environments.

No option is automatically secure. A per-tenant database does not prevent a compromised internal service account from connecting to every database. A shared table does not have to be unsafe if database controls, query design, and tests are mature. The best approach fits the product’s risk profile, compliance commitments, scale, and operational capability.

Defense in depth beats a single tenant filter

A tenant ID in application middleware is necessary, but it should not be the only safeguard. A stronger design uses overlapping controls:

• Put tenant identity into the authenticated principal and verify it at the API boundary.
• Require the tenant context in service-layer authorization decisions.
• Scope data access in the database, ideally with mechanisms such as row-level security where appropriate.
• Use per-tenant prefixes or policies for object storage, search indexes, caches, and queues.
• Issue short-lived credentials restricted to a tenant, action, resource, and time window.
• Partition or strictly namespace logs, analytics events, exports, and support tooling.
• Treat internal services as callers that must prove scope rather than trusted bypasses.

NIST’s zero-trust architecture guidance is useful here because it rejects implicit trust based simply on network location or asset ownership. Applied to SaaS, an internal worker, database client, support dashboard, or “platform admin” endpoint should not receive unrestricted access merely because it lives inside your cloud account. (csrc.nist.gov)

Enforce authorization on every resource, not just every screen

A familiar trap is building tenant isolation into the visible UI while leaving the underlying APIs under-scoped. A customer cannot see another workspace in the navigation, but can change an ID in a request, call an older endpoint directly, retrieve a file by URL, or use an export API with a guessed filter.

This is why authorization should be evaluated against the object being accessed, not inferred from the page a user came from.

A practical authorization rule

For every request, resolve four things:

1. Subject: Who or what is acting? This can be a user, API key, service account, webhook, worker, or support agent.
2. Tenant: Which customer boundary is active for this request?
3. Resource: What exact object, collection, secret, file, job, integration, or action is being requested?
4. Relationship and policy: Does this subject have the requested permission for that resource within that tenant?

The authorization decision should fail closed. If the service cannot resolve tenant ownership, it should deny the action—not assume the object is valid because the requester is signed in.

For example, GET /documents/:id should not ask only, “Is this user authenticated?” It should verify, “Does this document belong to the active tenant, and does this user’s role or relationship permit reading it?” A global UUID is not an authorization control. It may make enumeration harder, but it does not establish ownership.

Watch the non-obvious resources

Teams usually scope primary records such as projects, contacts, campaigns, and invoices. Cross-tenant exposure frequently appears in secondary systems that receive less review:

• file download and upload endpoints
• CSV exports and scheduled reports
• generated PDFs and email attachments
• asynchronous jobs and retry queues
• webhook histories and event replays
• object storage signed URLs
• search suggestions and autocomplete indexes
• logs, traces, error reports, and audit exports
• analytics dashboards and BI connectors
• feature flags, prompt libraries, templates, and secrets
• support impersonation and account-recovery flows

If an object can be named, fetched, generated, cached, transformed, or sent, it needs a tenant model.

Test tenant isolation as an adversarial product requirement

A normal QA test asks whether a user can create a workspace, invite a teammate, upload a file, and run a workflow. A tenant-isolation test asks whether a user from Workspace A can perform those same actions against Workspace B’s resources by manipulating every boundary in between.

The fastest way to make this repeatable is to create dedicated test tenants and turn cross-tenant denial into a release gate.

Build a two-tenant test harness

Create at least two synthetic organizations with visibly different data. Use identifiers and fixture values that make leaks unmistakable: Tenant A’s documents should contain a unique marker such as ALPHA-ONLY; Tenant B’s records should contain BRAVO-ONLY.

Then run automated tests in which each tenant attempts to access the other’s objects across every supported route, API version, job type, and integration.

Your baseline matrix should cover:

Add property-based and fuzz testing

Example-based tests catch known endpoints. Property-based testing can catch whole classes of mistakes. Generate random resource IDs, tenant contexts, roles, and endpoint sequences; assert that a response is either explicitly authorized or denied.

You should also fuzz the inputs most likely to bypass implicit assumptions:

• tenant IDs in query parameters, headers, and request bodies
• workspace IDs embedded in URLs
• pagination cursors and search filters
• cache keys and localization variants
• import files and webhook payloads
• bulk operation IDs
• asynchronous job metadata
• direct object-storage paths

A useful invariant is simple: no response, side effect, or error message generated under Tenant A should contain Tenant B’s protected data. That includes metadata such as names, counts, object IDs, provider configuration, and existence signals.

Test the backend without the frontend

The most important isolation tests are API-level and service-level tests. Browser UI constraints are easy to bypass with an HTTP client, SDK, old mobile build, browser developer tools, or automation script.

Test every endpoint directly, including internal endpoints behind gateways. If you use GraphQL, validate each resolver and nested relationship. If you use REST, test alternate verbs, legacy versions, filters, bulk endpoints, and error paths. If you use event-driven systems, test consumers as rigorously as HTTP handlers.

Secure secrets as tenant-scoped capabilities

The Flowise advisory makes secrets central to the story. In many SaaS applications, secrets are not just implementation details; they are delegated authority over external systems.

An OpenAI key can spend money. An AWS credential can access infrastructure. A Supabase service-role key can bypass ordinary application permissions. A Slack token can read or post in a customer’s workspace. Treating these as generic environment variables inside a shared process is often too coarse for a multi-tenant product.

Better patterns for secret handling

Prefer a secrets system that maps each credential to an owner, purpose, scope, and lifecycle. Instead of injecting every available secret into a function runtime, retrieve only the specific secret authorized for the active tenant and requested connector.

Use these controls together:

• Store tenant-owned secrets with immutable tenant ownership metadata.
• Enforce ownership again at retrieval time, not only when the secret is created.
• Avoid passing secrets through client-side code, logs, job payloads, or generic environment objects.
• Use separate credentials for platform operations and customer integrations.
• Issue short-lived tokens when a provider supports them.
• Scope cloud IAM roles to specific buckets, prefixes, databases, or queues.
• Redact sensitive values from logs, traces, error reporting, and support tools.
• Rotate credentials when exposure is suspected, rather than assuming a patch alone removes risk.

The published Flowise advisory recommended urgent remediation and revocation of potentially leaked credentials. That is appropriate because a code fix prevents future exposure; it cannot make previously viewed or copied credentials safe again. (github.com)

Operational controls matter after the code ships

Tenant isolation is not a one-time architecture decision. New integrations, migrations, performance optimizations, support tooling, and feature flags can introduce fresh cross-tenant paths long after the original application is secure.

A reliable program includes detection and response as well as prevention.

Log authorization decisions, not sensitive payloads

Record enough information to investigate access patterns: actor ID, active tenant ID, target resource type and ID, policy decision, endpoint, timestamp, and request correlation ID. Do not indiscriminately log secrets, prompts, raw documents, or access tokens in the name of observability.

Create alerts for unusual behavior, including:

• an account attempting many resource IDs outside its tenant
• repeated authorization denials across distinct tenants
• unusually large exports or connector activity
• access to secrets or configuration paths outside normal workflows
• support accounts switching tenants at abnormal volume
• worker jobs whose source and destination tenant IDs differ

These signals will not replace correct authorization, but they can shorten detection time when a defect or compromised account appears.

Make support tooling part of your threat model

Internal dashboards are frequently more privileged than customer-facing APIs. They may permit account lookup, impersonation, secret rotation, invoice adjustments, data exports, and troubleshooting access. If they treat tenant boundaries casually, they can become the easiest route to a large-scale incident.

Require strong authentication for staff tools, narrowly defined roles, explicit reason capture for sensitive access, short-lived impersonation sessions, and immutable audit records. A support agent should not receive a permanent unrestricted capability simply because they need to help one customer.

Related coverage: the same tenant-boundary lesson at cloud scale

The Flowise flaw was an application-level example: a customer-controlled feature was given visibility beyond its workspace. The principle also appears in infrastructure-level incidents.

Wiz’s July 2026 report on “CosmosEscape” described a vulnerability chain in Azure Cosmos DB’s Gremlin API that could have enabled access to databases across customers by exposing a platform-wide signing secret. Wiz said the chain could lead to full read and write access to any Cosmos DB account, and Microsoft remediated the issue. (wiz.io)

The technical details differ substantially, but the strategic lesson is the same: shared infrastructure depends on the correctness of boundaries. A platform-wide credential, shared runtime, overly trusted internal service, or improperly scoped execution environment can turn one customer’s foothold into access far beyond that customer’s intended reach.

For SaaS builders, this is why “we use a reputable cloud” is not a complete tenant-isolation strategy. Cloud providers secure major layers of the stack, but your application still owns authorization policy, data modeling, access paths, secret handling, and product-level capabilities.

A 30-day plan to improve multi-tenant SaaS security

You do not need to redesign every service before making meaningful progress. Start by identifying where a customer context could be dropped, forged, inherited too broadly, or ignored.

Week 1: map the tenant boundary

Inventory every resource that belongs to a tenant: database records, files, secrets, integration configurations, prompts, conversations, model outputs, background jobs, logs, reports, and billing data. For each, write down the authoritative ownership field and the service responsible for enforcing it.

Also list every code path that can read or change that resource. Include APIs, workers, cron jobs, internal tooling, imports, exports, webhooks, SDKs, CLI tools, and support workflows.

Week 2: identify ambient authority

Look for global credentials, process-level environment variables, shared object stores, unrestricted database connections, “admin” middleware, broad cloud roles, and caches lacking a tenant namespace.

Prioritize code-execution, workflow, plugin, and connector features. Ask a direct question: if a low-privilege customer can influence this execution path, what other tenants’ data or secrets are present in its process, memory, runtime object, or credentials?

Week 3: automate negative tests

Build the two-tenant test harness and add cross-tenant tests to CI for core APIs first. Make failed isolation tests block releases, just as failed payment, login, or data-loss tests would.

Do not stop at GET requests. Include create, update, delete, upload, download, search, export, share, invite, webhook, retry, and background-job flows.

Week 4: reduce blast radius and prepare response

Replace broad credentials with scoped and short-lived alternatives where possible. Remove secret exposure from runtime environments that do not need it. Ensure audit logs can answer which tenant, actor, resource, and credential were involved in a sensitive event.

Finally, write an incident runbook for suspected cross-tenant exposure. It should cover triage, feature containment, credential rotation, evidence preservation, customer notification decisions, and post-incident verification. A breach response is much faster when the team has already decided who can disable a risky feature and how to rotate affected secrets safely.

The business case for proving isolation

Founders sometimes see deep authorization work as invisible engineering that delays features. In reality, tenant isolation is product quality, revenue protection, and enterprise readiness.

Customers evaluating a SaaS platform increasingly ask where data lives, who can access it, how support access works, whether environments are logically or physically separated, and how secrets are handled. The best answer is not a vague assurance that “data is secure.” It is an architecture and testing story your technical team can explain clearly.

Strong isolation also makes product development faster over time. When every service uses a consistent tenant context, authorization model, secret retrieval pattern, and test harness, new features have a safer default path. Engineers do not have to reinvent ownership logic for every endpoint, and security review becomes more systematic.

The Flowise case is valuable precisely because it cuts through the false comfort of working authentication. The user was not anonymous. The system did not fail at the login page. The customer boundary failed inside an authenticated feature—and that is exactly where multi-tenant SaaS security needs to be continuously designed, tested, and monitored.

FAQ

What is multi-tenant SaaS security?

Multi-tenant SaaS security is the set of controls that protects customers sharing one application or infrastructure environment. Its central requirement is tenant isolation: one customer must not be able to access, alter, infer, or disrupt another customer’s data and resources.

Is authentication enough to prevent cross-tenant data leaks?

No. Authentication confirms identity, while authorization determines what that identity can access. A user can be legitimately authenticated and still exploit a missing ownership check, overbroad service credential, unsafe cache key, or poorly scoped custom-code runtime.

What did the Flowise vulnerability expose?

The published advisory for CVE-2025-59434 said authenticated Flowise Cloud users could access environment variables from other tenants through the Custom JavaScript Function feature before an August 2025 patch. Reported examples included API keys and cloud credentials, and the advisory stated researchers retrieved 514 variable names. (github.com)

How do I test tenant isolation in a SaaS app?

Create at least two test tenants with distinct fixtures. For every API, file, job, search result, export, integration, and internal tool, verify that Tenant A can access its own resource and is denied when attempting the same action against Tenant B’s resource. Run these negative tests automatically in CI.

Should every SaaS use separate databases for each tenant?

Not necessarily. Separate databases can strengthen a boundary, but they add operational complexity. Shared databases can be safe when tenant context is enforced at the application and database layers, resources are correctly namespaced, secrets are scoped, and cross-tenant testing is continuous.