Case study 01 · External · Cloud · Web app
Entire subscriber table open on the public internet, closed and re-verified mid-engagement
A consumer-facing SaaS product that collects personal profile data from the people who sign up for it. Small production estate: a single-page web application on a managed hosting platform, backed by a hosted cloud database and a transactional email service.
Client profile
A consumer-facing SaaS product that collects personal profile data from the people who sign up for it. Small production estate: a single-page web application on a managed hosting platform, backed by a hosted cloud database and a transactional email service.
Challenge
The product holds personal records for everyone who enrols. The question for the assessment was direct: could an outsider with no account reach that data, and could the brand be used against the same people it serves?
Scope
- Production web application and its public JavaScript bundles
- The hosted cloud database behind the application
- Email authentication posture (SPF, DKIM, DMARC) for the primary domain
- Application API routes discovered through bundle analysis
- Content backend reviewed passively only
Authorized external red team, black-box, active probing against live production.
ApproachAI-accelerated, human-validated
A black-box external engagement run on TitanDef's agent-orchestrated pipeline and powered by frontier models: passive reconnaissance, active enumeration, cloud and bundle analysis, then live validation. Every candidate finding was confirmed against canary records created for the test, and each confirmed finding was reviewed by a senior human before it entered the report. The seven refuted hypotheses are documented alongside the findings so the negative results are on record.
Key findingsby severity
24 validated findings · 7 hypotheses refuted
Critical
- The application's cloud database key was published inside its own public JavaScript. Any anonymous visitor could read the full subscriber table (hundreds of records: names, contact details and device profiles). The same access allowed records to be reassigned, turning a read exposure into active manipulation of subscriber data.
- Email from the primary domain could be freely impersonated (DMARC set to monitor-only, no DKIM signing), so subscribers could be targeted with mail carrying the brand's own trusted identity.
High
- Eight High findings, including stored cross-site scripting, no account lockout, privilege fields accepted at sign-up, client-side-only gating of the dashboard, and an unauthenticated AI endpoint reachable without a credential (a cost-abuse exposure).
A single zero-credential sequence, from the open database to a brand-identical phishing run against the same subscribers, was demonstrated end to end in roughly fifteen minutes. The record count rose while we watched during the two-day window, as new subscribers continued to enrol into the unprotected table.
Outcomefixed / retested
The two database Critical findings were remediated during the engagement and re-verified live three days after testing began: with database-level row security applied, the anonymous read and insert path was confirmed closed against the same public key. The remaining Critical (email impersonation) was left open at report time as the single priority action, with a sequenced DNS fix supplied.
Days 1-2
Testing. Database exposure and the end-to-end chain confirmed against canary records.
During the window
Client applied row-level security to the exposed table.
Day 3
Re-verified live: anonymous read and insert closed; finding, fix and re-test evidence all shipped in the 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.