The customer portal looks right. Each account sees its own projects, the demonstration works, and the export button produces a file. Before accepting the feature, there is a more consequential question: does the same customer boundary hold when data leaves the screen?
For a CTO responsible for a B2B SaaS product, tenant isolation means that a customer can access only the resources and actions their organisation and role permit. An organisation might be called a workspace, account or tenant. The name matters less than the rule the application must enforce.
Public security advisories make this distinction concrete. A notification subscription, an export and a normal request can fail at different boundaries. Checking one route does not establish what happens on the others.
Answer in 60 seconds
Choose one customer journey and write down the access it must permit and deny. Follow the data through the request, any background job, the resulting file and realtime delivery. Ask for evidence from an authorised test environment with synthetic customers, including a working permitted case alongside each denied case.
Keep the conclusion as narrow as the evidence: which role, resource, action, delivery route and build were checked? An untested export or notification path remains untested even when the main page behaves correctly.
1. Define the customer boundary before checking it
“Users must be logged in” answers an identity question. It does not answer whether this user may read this document, export this report or receive this organisation’s events.
On a call with a CTO, we put it this way: “Logging in tells the server who is asking. It does not tell it what that person may have. Every request, file and notification still has to answer: does this person’s organisation own this record?”
OWASP’s API1:2023 guidance calls this object-level authorisation: checking permission for the requested action on the requested resource. It lists UUIDs alongside sequential integers as identifiers an attacker can manipulate, so an opaque identifier is not that permission.
Advice we argue with: “the IDs are UUIDs, so nobody can reach those records.” A hard-to-guess identifier still travels in exports, logs, shared links and notifications, so it cannot replace the permission check. The check we treat as mandatory is a pair on every delivery route: one permitted request, and one denied request from a second organisation.
Write the rule in product language. For example: a member of organisation A may read A’s support tickets; an administrator of A may export A’s tickets; neither role may obtain B’s tickets. If a support operator legitimately works across customers, document that separate authority and its limits.
This gives engineering and product the same reference. A failed request is meaningful only when the request should have failed. A successful request is meaningful only when its result contains the permitted data.
2. Two advisories, three different boundaries
These are publisher-described mechanisms, not tests performed by IZZY.
Daytona’s June 2026 advisory describes a notification gateway that accepted an organisation selection without checking membership on its JWT path. An authenticated user could receive another organisation’s realtime events. The advisory states that the API-key authentication path was not affected.
ToolJet’s August 2026 advisory describes two export boundaries: disclosure of TooljetDB table schemas across workspaces, and export of another app’s definition within the same workspace beyond granular app permissions. Table schemas are not table rows; the second mechanism is not described as cross-workspace app export.
| Published mechanism | Question to carry into your own acceptance review |
|---|---|
| Daytona: organisation membership at subscription | What authorises delivery of this organisation’s notifications? |
| ToolJet: workspace boundary for schema export | Which customer owns the material the export selects? |
| ToolJet: app permission within a workspace | Does permission for one app extend to exporting another? |
The comparison changes what to request from a team. “We checked login” leaves the subscription decision unanswered. “We checked the workspace” can leave a resource-level permission unanswered.
These advisories do not establish your product’s vulnerability, exploitation in the wild or the vendors’ current deployment status. Their inconsistent severity metadata is unnecessary to this comparison; no severity score is used here.
3. Follow one customer record through the feature
Consider an illustrative support portal. Organisation A has a synthetic ticket marked A-DEMO; organisation B has one marked B-DEMO. These are fictional fixtures, not customer records or a reconstruction of either advisory.
An A administrator opens the ticket list, requests a report, waits for the export job, downloads the file and receives a completion notification. Treat that as one product journey with several decisions:
- The request selects tickets the administrator may read.
- The background job retains the intended organisation and export scope.
- The generated file contains the permitted records.
- The download follows the product’s agreed access or sharing rules.
- The notification reaches its intended audience with permitted content.
For each transition, identify which component enforces the rule. A screen filter does not explain how the exporter selects its data. An authorised job does not explain who can retrieve its result.
Make sharing behaviour explicit. If a report uses a temporary bearer link, anyone holding it may be intended to have access during its validity. That is a product decision to document and test, including expiry and revocation expectations. Do not silently evaluate it as though it required a fresh login.
4. Ask for allowed and denied evidence together
The following is an acceptance example for that fictional portal. The expected results must be adapted to the actual product policy before testing; the table contains no observed results.
| Route | Expected permitted case | Expected denied case | Evidence to retain |
|---|---|---|---|
| Ticket request | A member reads A-DEMO |
A member cannot read B-DEMO |
Role, fixture, response and build |
| Report creation and file | An A administrator with export rights gets the intended A records | The same operation cannot include B records | Job context and inspection of the synthetic output |
| Restricted role | A viewer can read the tickets their role permits | The viewer cannot export if the policy withholds that action | Both outcomes under the same role policy |
| Realtime delivery | A’s intended event is received | B’s event is not delivered to A | Event fixtures, subscription decision and observation window |
A silent realtime client is weak evidence on its own: perhaps no event was emitted or the connection failed. Confirm that the permitted event was produced and received, then inspect the denied subscription or delivery evidence within a defined window. Record any uncertainty instead of turning silence into a pass.
Run only in environments and accounts whose testing is authorised. Synthetic fixtures let the team show a boundary without retrieving another real customer’s information. Stop at the agreed proof; an acceptance review does not need a bulk-data demonstration.
5. Choose a repair that covers the failing route
OWASP’s multitenant guidance treats tenant context, data access, caches, asynchronous work and storage as connected concerns. Database isolation is one layer; it cannot stand in for checking the paths the application actually uses.
When an acceptance case fails, locate the decision that went wrong. Was the selected organisation trusted without membership verification? Did the worker lose the scope? Did a resource-specific permission disappear when an export was added? The answer should determine the correction and the nearby cases to recheck.
Keep the permitted case in that recheck. A repair that denies every export may remove the observed disclosure while leaving the promised feature unusable. Also run through the application’s normal runtime identity and configuration: a result obtained under a different test-only access path answers a different question.
For personal data, the CNIL’s API security guidance (in French) also asks organisations to identify the actors and their roles in order to define each one’s access to APIs and data, and to limit sharing to strictly necessary data, intended people and intended purposes. That supports examining the whole sharing journey; it does not certify a particular implementation as compliant.
6. Accept the evidenced boundary, then name what remains
Before the release decision, bring together the intended rule, the checked build and environment, the permitted and denied results, the correction owner, and the routes not examined. “Requests checked; export download not examined” is a useful conclusion because someone can act on the remaining question.
Where we draw the line: after a limited review, we name the routes, roles and build we checked. We do not call the product isolated on the strength of routes we did not test.
If another team will operate the product, keep that record with the codebase handoff evidence. If a finding requires a released correction, assign ownership through that release and its verification, as in the maintainer security workflow.
Start with the next customer-data feature your team must accept. Ask the owner to explain one allowed journey and one forbidden journey through every delivery route. The first missing answer identifies the next review task.
Check the boundary with us
If the boundary is difficult to trace through an inherited codebase, bring the journey, architecture and existing test evidence to a discussion about IZZY’s codebase remediation and hardening work. That is an engineering preparation or correction conversation. Arrange independent penetration testing separately when that assurance is required.
Sources and limits
Research synthesis checked on 10 November 2026. The linked Daytona and ToolJet advisories describe different historical mechanisms; no exploit was reproduced and no claim is made about current affected deployments. OWASP and CNIL provide guidance, not verification of the illustrative portal. The portal, fixtures and expected outcomes above are examples to adapt, not an IZZY client case or a complete security assessment.