A fictionalized demonstration of THF reporting for SaaS authorization, IDOR/BOLA validation, privilege boundaries, tenant isolation, and business-logic access-control risk.
Tenant Authorization Requires Immediate Attention
A fictionalized multi-tenant SaaS platform was reviewed across customer-record APIs, role-based workflows, export actions, GraphQL resolvers, and administrative permission boundaries.
Testing confirmed multiple broken access-control paths where a standard authenticated user could reach restricted records or privileged actions without the required tenant ownership validation.
Authorization Model Overview
| Boundary | Purpose | Security Focus | Status |
|---|---|---|---|
| Tenant isolation | Separate customer workspaces and records | Workspace ownership validation | Reviewed |
| Role enforcement | Restrict actions by assigned role | Privilege escalation and role tampering | Reviewed |
| Object-level access | Protect individual records and exports | IDOR, BOLA, nested object access | Reviewed |
| Administrative workflows | Control restricted actions | Server-side authorization checks | Reviewed |
Role and Permission Boundary Review
| Surface | Coverage | Roles | Status |
|---|---|---|---|
| Customer Records API | Read, update, export, and nested record access | Standard / Manager / Admin | Reviewed |
| Billing records | Invoices, subscriptions, and workspace billing data | Standard / Admin | Reviewed |
| Invite workflow | Role assignment and user onboarding actions | Member / Admin | Reviewed |
| Out of scope | Physical testing, phishing, DoS, source-code review | — | Excluded |
Tenant Isolation Validation
- Cross-tenant object access through missing ownership validation.
- Privilege escalation through role or tenant identifier manipulation.
- Unauthorized exports of restricted records.
- GraphQL resolver access without object-level authorization.
- Administrative actions exposed to standard users.
Authorization Decision Flow
The access-control review validates whether each protected action reaches a server-side permit or deny decision through tenant, object, role, and business-rule checks.
Cross-Tenant Access Testing
Map tenants, roles, objects, and protected workflows.
Capture valid requests across normal user journeys.
Manipulate object IDs, tenant IDs, role claims, and GraphQL variables.
Validate server responses, side effects, and access-control decisions.
Document evidence, business impact, remediation, and retest criteria.
Access Control Risk Summary
| ID | Finding | Severity | Status |
|---|---|---|---|
| THF-AC-001 | Cross-Tenant Record Access | Critical | Open |
| THF-AC-002 | Privilege Escalation Through Role Manipulation | Critical | Open |
| THF-AC-003 | Missing Ownership Validation on Export Endpoint | High | Open |
| THF-AC-004 | Insecure Direct Object Reference in Billing Records | High | Open |
| THF-AC-005 | Admin Action Exposed to Standard User | Critical | Open |
| THF-AC-006 | GraphQL Resolver Missing Object-Level Authorization | High | Open |
| THF-AC-007 | Invite Workflow Allows Unauthorized Role Assignment | Medium | Open |
| THF-AC-008 | Internal Object Identifiers Exposed | Low | Open |
THF-AC-001 — Cross-Tenant Record Access Through Missing Ownership Validation
Critical
Category: Broken Access Control / BOLA / IDOR
CWE: CWE-639
Affected Component: Customer Records API
Required Access: Standard Authenticated User
Risk: Unauthorized access to another tenant’s records
Finding Summary
The Customer Records API accepted a record identifier from the client and returned the requested object without validating that the authenticated user belonged to the same workspace as the protected record.
Cross-Tenant Exposure Risk
This issue could expose customer records across organization boundaries, allow unauthorized access to restricted business data, damage customer trust, create contractual and compliance exposure, and increase incident response burden if exploited at scale.
Illustrative Request and Response Evidence
Expected Behavior
GET /api/v1/customer-records/rec_workspace_b_7429 HTTP/1.1
Host: app.example.invalid
Authorization: Bearer <workspace-a-user-token>
X-Workspace-ID: workspace_a
HTTP/1.1 403 Forbidden
{
"error": "record_not_accessible"
}Observed Behavior
GET /api/v1/customer-records/rec_workspace_b_7429 HTTP/1.1
Host: app.example.invalid
Authorization: Bearer <workspace-a-user-token>
X-Workspace-ID: workspace_a
HTTP/1.1 200 OK
{
"record_id": "rec_workspace_b_7429",
"workspace": "Workspace B",
"resource": "Protected Resource"
}Safe Sanitized Reproduction
- Sign in as a standard user in Workspace A.
- Capture a valid request for an owned record.
- Replace the record identifier with a fictional Workspace B record ID.
- Replay the request.
- Observe unauthorized access with HTTP 200.
Recommended Fixes
- Enforce tenant ownership server-side.
- Validate object ownership on every read, update, and export action.
- Do not trust client-provided tenant or role identifiers.
- Centralize authorization checks.
- Add regression tests for cross-tenant access.
- Log repeated object-ID probing.
- Review GraphQL resolvers and nested object access.
- Apply deny-by-default authorization behavior.
Access-Control Retest Criteria
- Authorization is enforced in the server-side data-access layer.
- Every object lookup validates tenant and ownership before returning data.
- Role changes and privileged actions require explicit permission checks.
- GraphQL resolvers enforce object-level authorization for nested resources.
- Security tests include negative cases across users, tenants, and roles.
Engineering-Ready Output
- Executive summary and validated access-control risk summary
- Authorization model and testing scope
- Sanitized evidence and reproduction steps
- Business-impact analysis
- Remediation guidance
- Retesting criteria
Validate Your Access Control Before Attackers Do
Share the product area, API, release, or workflow you want reviewed. THF will respond with practical scoping questions and a recommended access-control testing approach.