Authorized AI Pen Test of a Client Web App

A client came to us with a live web application they did not build themselves. They did not fully trust the security of the work that had been delivered to them, and they wanted an independent party to challenge it the way a real attacker would, before their users paid the price. So they authorized us to test it. This is what authorized, independent security testing of someone else’s build looks like, with every client, user, and application identity removed.

Important notice. This case study is published for general informational and educational purposes only. It describes outcomes and impact at a high level; it deliberately leaves out reproducible steps, payloads, and any identifying detail, both to prevent misuse and to protect the systems and people involved. Everything described was carried out with the explicit written authorization of the system owner, within an agreed legal scope. Security testing without that written authorization is illegal. Nothing here is an instruction or an encouragement to test, access, or interfere with any system you do not own or are not authorized in writing to test, and Dabster Labs accepts no liability for any action taken on the basis of this content.

We did not write a line of this application. That is the point of the engagement: an owner who wanted the work checked by someone with no reason to go easy on it.

Authorization first: consented, scoped, confidential

Authorization to test is not implied and it is not a formality. It was established up front and in writing, and it framed everything that followed: explicit written consent from the owner before any testing began, an agreed scope of what was and was not in play, write-to-production pre-authorized in writing because proving certain issues meant writing real records, and a confidential report delivered to the owner and no one else. This public case study exists only in anonymized, generalized form.

How we ran it

We ran an autonomous AI penetration tester against the live deployment in black-box mode, with no source and no credentials, across two full passes: a first pass of roughly three hours, and a post-fix re-attack pass of roughly eight hours overnight. Alongside it we ran custom attack agents that independently reproduced findings, a load test configured for up to ten thousand virtual users, and anti-automation resilience testing. Then a human re-verified every AI claim by hand. We describe the shape of the work and its outcomes here, never the reproducible specifics, which stay in the owner’s confidential report.

The part that actually matters: judgment

We use AI agents to accelerate security testing, but AI on its own is not trustworthy. During this engagement we rejected two of its claimed exploits as AI hallucinations, including a fabricated “password cracked” result that had simply not happened. A human re-verified every machine-produced claim by hand, and only owner-verified findings made it into the report. An AI security tool that is never checked will invent breaches. Ours is checked, every single time, which is exactly why an owner can trust the report rather than a raw machine dump.

What we found, at a glance

We describe outcomes and impact, never reproducible requests, and any still-open item is named at the category level only. The engagement identified 23 distinct security issues, of which 11 were fully exploited, proven by writing real records into the production database using only a public client key. The categories included:

• Missing row-level security exposing user-scoped data: absent on 10 of 11 user-scoped tables at audit time, leaving roughly 22 registered users’ data readable and writable.
• Subscription and entitlement fields writable by an anonymous caller.
• An unauthenticated access-control gap in the payment flow.
• Authentication misconfiguration enabling instant account claiming.
• Session refresh tokens held in browser local storage, an account-takeover risk under any cross-site scripting.
• No rate limiting: 150 login attempts produced zero throttling, and 20 accounts were created in 28 seconds.
• A leaked third-party API key present in the client-side bundle.
• An OAuth open redirect, and an AI prompt-injection surface via unsanitized user text.
• Missing security headers.

GDPR and AI-safety findings, at altitude

Two findings deserve a specific mention for an EU-first audience, both stated with zero user data, zero content, and zero identity. First, a GDPR Article 9 exposure: special-category personal data was readable at audit time. We flag it as a category and a legal risk; we reproduce not a single record. Second, an AI-assistant safety failure: we test AI assistants for crisis-handoff behaviour, and found a case where the assistant should have handed off to crisis resources and did not. We report that the failure class exists; we publish nothing about the message or the person.

We drive the fix, and prove it holds

The strongest issue was addressed during the engagement, not after it. Mid-audit the owner applied row-level security and owner-only access policies, and our second attack pass then confirmed that cross-user reads, writes, and deletes were blocked. Finding a hole is table stakes. Watching the fix go in and re-attacking to prove it holds is the part an owner genuinely pays for.

Why independent, authorized testing matters

When you did not build a system, you cannot see its blind spots, and neither can the people who did. An independent tester with written authorization and no stake in the original work is the surest way to find out what a real attacker would find first. Authorized testing uses a real attacker’s mindset, with permission, against a system whose owner wants to know where it is weak, kept confidential and used only to make it stronger.

Inherited a system you are not sure you can trust? Ask Dabster Labs for an authorized security assessment and get a prioritized fix-and-retest plan, not a scare document.