Case study 04 · External · Web app · Authenticated
The lowest-privilege account reads the whole internal admin surface
A business-operations SaaS application serving several business clients from one deployment, with a built-in AI assistant.
Client profile
A business-operations SaaS application serving several business clients from one deployment, with a built-in AI assistant.
Challenge
Every employee and every client user gets the same low-privilege role. The central question was simple: what can the least-privileged account actually reach, and does the tenant boundary hold under the hood?
Scope
- The production application and its API
- Both the unauthenticated surface and the authenticated surface, tested as a client-provided lowest-privilege account
- A server-side request forgery lane on a connection health-check
- A live prompt-injection and cross-tenant lane against the built-in AI assistant
- Destructive tests run against canary data and reverted
Black-box external application penetration test, with a low-privilege member account provided mid-engagement.
ApproachAI-accelerated, human-validated
A black-box application test on TitanDef's pipeline, powered by frontier models and aligned to PTES and OWASP. A real-browser walkthrough established the unauthenticated surface; all authenticated testing ran as the lowest role the product issues, covering authorization, tenant boundaries, business logic, mass assignment and input validation. Findings were proven live and human-reviewed, and the controls that held were credited as validated positive controls, including the AI assistant's guardrails.
Key findingsby severity
10 validated findings
Critical
- Most of the internal administrative routes enforced no server-side role check. The lowest-privilege member session could read the operator's internal admin surface (internal topology, staff support tickets, and the multi-tenant deployment map) and write to an internal workflow queue, with no privilege escalation and no exploit code. Broken function-level authorization, CVSS 9.1.
High
- Five High findings: a self-approvable quote workflow with no maker-checker; a cross-tenant user-directory disclosure exposing every client's roster to any member; the production backend for all tenants running on a single unmanaged personal machine; one shared database file behind every tenant with no database-level isolation; and a blind server-side request forgery with an internal port-scan oracle.
Three end-to-end chains were confirmed. The structural driver is that a single shared database on one host backs every tenant, so one exposure has a multi-client blast radius.
Outcomefixed / retested
The direct exposure closes with a mechanical fix: apply the role guard the codebase already enforces elsewhere to every internal route. The blast radius closes by moving the backend onto managed, per-tenant-isolated infrastructure. Fifteen validated positive controls were credited, including five guardrail controls on the AI assistant that held on every probe. The remediation roadmap lists a full re-verification and an authorization regression suite as the closing step.
Immediate
Extend the existing admin-role guard to every internal route; enforce maker-checker on the approval workflow.
30-90 days
Move the backend onto managed, per-tenant-isolated compute; add an authorization regression test.
Retest
Re-verify each remediation and re-run the authorization regression suite.
In the report
“there is no “regular user” tier that is actually contained.”Most significant observation, application penetration test report
Engage
Find out what an adversary already sees.
Focused engagements of 5 to 7 business days, with first findings in 72 hours. Powered by frontier models; every finding validated by a senior human.