zypher.co / reports / getconnects signed in · client link
Penetration test report

GetConnects

Multi-tenant API authorization assessment
April 2026 Delivered 2026-04-23
Risk index
98
/ 100
Severity distribution
Critical
3
High
1
Medium
1
Low
0
Info
0
Executive summary

The assessment identified multiple authorization weaknesses in how the platform enforces organisation boundaries and user roles. Unauthenticated users can retrieve organisation data, authenticated users can read data belonging to other organisations, and non-admin users can reach administrative functionality. A single low-privilege session in any organisation can read across the entire platform if the target's organisation identifier is known or guessed; sensitive data recovered during testing included contact records, SMS content, and campaign scheduling metadata.

Exploitation does not require complex primitives. Each finding is a one-shot request that swaps the authenticating session's own organisation identifier for a target one. The pattern points at inconsistent enforcement of authorization across endpoints rather than a single isolated flaw.

Engagement
Client
GetConnects
Target
Multi-tenant SaaS API (host redacted)
Scope
API authorization, tenant isolation, role-based access control
Window
April 2026
Methodology
OWASP API Security Top 10 (BOLA, BFLA)
Status
Delivered; remediation and retest cycle in progress
How to read this engagement. Each finding is published as its own report (linked below) with the full description, proof of concept, impact, root cause, and recommendation for that specific vulnerability. This page is the engagement overview: executive summary, findings table, root cause across the five, and links out.

Findings

5 total
01 Critical
F-01: Unauthenticated cross-tenant data access
BOLA, OWASP API1 · POST /api/segment/evaluate
9.8 reported +
02 Critical
F-03: Cross-tenant analytics and PII exposure
BOLA, PII, SMS content · POST /api/analytics/admin-events
9.6 reported +
03 Critical
F-05: Admin endpoint accessible to non-admin users
BFLA, OWASP API5 · POST /api/shift/adminGetAll
9.1 reported +
04 High
F-02: Unauthorized segment creation across tenants
BOLA on write path · POST /api/segment/create
8.8 reported +
05 Medium
F-04: Organisation ID enumeration in analytics UI
Enumeration primitive · Analytics UI
6.5 reported +

Root cause across the five

  • No consistent organisation membership check at the middleware layer; enforcement is per-handler and inconsistent.
  • Role-based access control is applied inconsistently across endpoints.
  • Client-supplied identifiers are used as the source of truth for tenant scoping.

The pattern aligns with OWASP API Security Top 10 categories BOLA (API1) and BFLA (API5): authorization exists in parts of the codebase but is not applied uniformly, and the gaps only surface under adversarial testing.

Recommendations across the five

  1. Centralise tenant scoping in a request middleware. Every handler receives the tenant identifier from the authenticated session, never from client input. Endpoints that legitimately need cross-tenant access become explicit opt-ins with their own gate. Add a role guard in the same chain, keyed to the specific action rather than a generic isAdmin flag.
  2. Deprecate client-supplied organisationId on read endpoints. Where a UI needs to switch between organisations the user actually belongs to, the server filters the list before serving it and rejects any identifier not on that list.
  3. Verify continuously. Log tenant boundary violations at the middleware layer even when a request would otherwise pass, and add a CI check that runs the top ten sensitive endpoints under three synthetic sessions (unauthenticated, low-priv-A, admin-B), failing the build if any returns data outside the caller's scope.

Timeline

DateEvent
Engagement window; five findings delivered on .
Following weeksRemediation and retest cycle.
Individual finding writeups published.

References

Remediation in progress Delivered 2026-04-23 Published 2026-07-12
More reports →