This one is a useful counterpoint to most of the audits I write about here, because the app wasn’t vibe coded. It was built by a technically competent team, and it showed.

The platform was a discovery and governance layer for AI integrations, targeting enterprise and regulated-industry customers directly. The product marketed per-member access tokens, tool allowlists, and audit logging as core selling points. Given that positioning, the bar going in was higher than a typical pre-launch scan. A platform selling governance and access control to regulated industries has to actually hold up under that same scrutiny itself.

What the engagement covered

Frontend bundle analysis for exposed secrets, HTTP security header configuration, authentication flow and rate limiting, session and token handling, Local Storage contents, search and API parameter injection, and SSL/TLS configuration.

What we found

The platform passed nearly everything a standard audit checks first. The frontend bundle contained no hardcoded API keys, no static Bearer tokens, and no exposed service credentials of any kind. Every match on common credential patterns resolved to dynamic template literals rather than real secrets. Security headers scored a full A grade, with CSP, HSTS, and the full standard header set present. Authentication ran on magic-link and OAuth only, removing the password brute-force surface entirely. The OTP rate limit was tested directly and held. Search and sort parameters were tested for injection and ignored safely server-side.

None of that surfaced the real problem. The issue showed up through ordinary use: after logging out and navigating back through browser history, the session behaved as though it were still active. That observation became the basis for a direct authentication logic test.

The session token remained fully valid after logout. It did not expire, did not get revoked server-side, and continued auto-renewing its 30-day validity window on every subsequent request. The same token, replayed in a completely separate incognito browser session, returned a full authenticated user object with no additional login step. Logging out, in practice, did nothing.

That flaw compounded with a second issue. The session endpoint returned a full set of personal data on any valid token: name, email, internal user ID, username, linked OAuth identity, verification status, and subscription tier. Because the logout flaw meant tokens never actually died, anyone in possession of an old or orphaned token retained standing access to that entire data set indefinitely.

A third, lower-severity finding was a debug flag from a third-party error monitoring SDK left active in production Local Storage, capable of leaking verbose request payloads and internal state to the browser console under the right conditions.

How verification worked

The core finding was confirmed through direct proof of concept, not inference. A valid session token was captured from an authenticated browser session. The user then logged out through the normal UI flow. That same token was manually injected into a fresh incognito session with no prior authentication state. The request succeeded and returned the full authenticated user object, confirming the server-side session was never actually terminated. The PII exposure was confirmed by inspecting the live response body of the session endpoint under that same replayed token. Rate limiting and injection resistance were confirmed as passing through direct, repeated testing against the live endpoints.

Outcome

The findings were compiled into a full report: an executive summary calling out the gap between the platform’s enterprise-governance positioning and the actual state of its session handling, each finding documented with severity, business impact, and a working proof of concept, and a remediation priority table. The session invalidation flaw was flagged as requiring the most urgent attention, given the platform’s own marketing promises around access control for regulated customers.

A note for technically competent teams

This engagement is worth pointing to specifically because it wasn’t an AI-generated app with obvious surface-level gaps. No hardcoded secrets, strong headers, functioning rate limits. The checks that catch most vibe-coded apps all passed cleanly here. What got missed was a logic-level flaw in how sessions actually terminate, the kind of issue that doesn’t show up in a header scan or a secrets grep and only surfaces when someone tests the actual behavior of logging out, not just the appearance of it.

Competent engineering teams reduce the obvious risks. They don’t eliminate the need for someone testing auth logic the way an attacker would.