A fictionalized demonstration of THF reporting depth for a multi-tenant SaaS product. Manual testing focused on APIs, access control, tenant isolation and business logic.
Tenant Isolation Requires Immediate Attention
Authorized Test Boundaries
| Surface | Coverage | Roles | Status |
|---|---|---|---|
| Web application | Auth, sessions, workflows | Standard / Admin | Reviewed |
| REST API | Objects, exports, integrations | Workspace A / Workspace B | Reviewed |
| Out of scope | DoS, social engineering, physical testing | — | Excluded |
Manual Product-Context Testing
Confirm product areas, roles, tenants, test accounts and sensitive workflows.
Map exposed routes, APIs, objects, integrations and trust boundaries.
Review login, session handling, reset flows and access-state transitions.
Test horizontal, vertical and tenant-boundary authorization controls.
Exercise object access, exports, bulk actions, state changes and edge workflows.
Look for workflow abuse that automated scanners rarely understand.
Reproduce findings safely and confirm impact with authorized test data.
Prioritize findings by exploitability, data sensitivity and business impact.
Provide engineering-ready fixes and retesting criteria.
Coverage is informed by OWASP ASVS, OWASP WSTG and the OWASP API Security Top 10, then extended through manual product-context testing.
Validated Risk Distribution
Likelihood vs Business Impact
Exploitation required only a standard authenticated account and a modified object reference.
The weakness crossed tenant boundaries and exposed protected customer records.
Unauthorized data access creates customer trust, contractual and regulatory risk.
Validated Findings
| ID | Finding | Severity | Status |
|---|---|---|---|
| THF-001 | Cross-tenant record access | CRITICAL | Open |
| THF-002 | Privileged export available to standard users | High | Open |
| THF-003 | Excessive customer metadata | Medium | Open |
| THF-004 | Session remains active after reset | Medium | Open |
| THF-005 | Internal object identifiers exposed | Low | Open |
THF-001 — Cross-Tenant Record Access
The endpoint verifies that the requester is authenticated but does not confirm that the requested record belongs to the requester’s tenant. A Workspace A user can replace a valid identifier with a Workspace B identifier and receive the record with HTTP 200.
The issue breaks a core SaaS security guarantee and could expose customer records across tenant boundaries.
Authorization: Bearer [Workspace A token]
HTTP/1.1 200 OK
A low-privilege user authenticated in Workspace A modified an object identifier to reference a protected Workspace B record.
The issue was manually reproduced using a low-privilege test account. Requests were modified to reference resources outside the authorized tenant boundary. The API returned data belonging to another tenant, confirming missing server-side authorization enforcement.
Apply tenant ownership checks in the data-access layer for every read, update, delete, export and batch operation.
The original request and adjacent object-access workflows must return denied responses for cross-tenant resources while valid same-tenant workflows remain functional.
A Core SaaS Security Guarantee Is Broken
- Cross-tenant disclosure of customer records
- Contractual and regulatory exposure
- Potential bulk extraction if identifiers are enumerable
- Customer confidence and incident-response impact
Observed Authorization Failure
Expected
Content-Type: application/json
{ “error”: “access_denied” }
Observed
Content-Type: application/json
{
“record_id”: “rec_demo_8421”,
“workspace_id”: “workspace_b”,
“customer_name”: “[REDACTED]”,
“status”: “active”
}
Reproduction Steps
- Sign in as the Workspace A standard user.
- Capture a valid record request.
- Replace the record identifier with the authorized Workspace B test record.
- Send the modified request.
- Observe HTTP 200 and confirm the token still belongs to Workspace A.
No administrative role was required. Testing was limited to authorized test records; no production customer data was accessed.
Enforce Ownership in the Data-Access Layer
Apply the authenticated tenant context to every server-side object lookup. Do not accept tenant identity from client-controlled input, and deny access by default.
id = request.record_id,
tenant_id = authenticated_user.tenant_id
)
- Constrain read, update, delete, export and batch operations
- Centralize authorization policy where practical
- Add automated cross-tenant regression tests
- Log repeated object-identifier probing
- Review adjacent endpoints using the same object model
Security Engagement Timeline
This sample deliverable represents the end-to-end reporting flow used during a focused SaaS security engagement, from scope confirmation through retesting.
Our Testing Philosophy
The Hidden Finds focuses on real-world security testing, not automated vulnerability dumps. Our assessments prioritize exploitability, business impact, access control, API behavior, tenant isolation, and workflow abuse. Every finding is manually validated before being reported.
Engineering-Ready Output
- Executive summary and validated risk summary
- Scope, methodology and technical findings
- Sanitized evidence and reproduction steps
- Business-impact analysis and remediation guidance
- Engineering prioritization and optional remediation discussion
- Retest support and final status update
See What a Focused Review Would Find
If your team needs SaaS, API, access control, AI workflow, or business logic testing, The Hidden Finds can help scope the right review and deliver practical next steps.
Request a Security ReviewView Resources
NDA available • Scoped SOW • Secure access coordination • Retesting support