Identified 3 critical auth bypasses and a privilege-escalation chain before public launch

Context

A Series A fintech was preparing for its first public B2C launch — a regulated lending product targeting Indian consumers. The platform consisted of a customer-facing web app, an internal back-office, and an API surface used by both. The engineering team had moved fast through alpha and beta, and the security review had been pushed to the final fortnight before launch.

Our brief was simple: find everything that should not ship.

Scope

Two weeks of testing across:

• Customer web application (Next.js + REST API backend)
• Back-office application (React + the same backend API)
• Public API surface (~40 endpoints)
• Third-party integrations (KYC provider, payment gateway, credit bureau)

Out of scope: the third-party providers themselves, the underlying cloud account (covered separately), and the mobile apps (still in development).

The critical findings

Three findings rated critical. All three were authentication bypasses on the same backend, but the root cause differed in each.

1. JWT validation bypass via the none algorithm. The backend trusted the JWT header without normalising the algorithm. An attacker-supplied alg: none token was accepted as valid for any user identifier.
2. Authorisation-bypass on a refresh endpoint. The refresh-token flow did not re-check the user’s tenant membership. A revoked back-office account could refresh into an active customer session by chaining a stale refresh token with a current customer ID.
3. OAuth state parameter not validated. The Google OAuth integration ignored the state parameter on callback, allowing CSRF-style account takeover via an attacker-controlled OAuth flow link sent to the victim.

The privilege-escalation chain was uglier: a low-privilege customer account could reach an admin-only endpoint by combining a mass-assignment flaw on the profile-update endpoint with a flawed role-resolution check on the back-office API. The chain was demonstrated end-to-end with a five-step PoC video that the engineering team used as the basis for their fix.

Remediation and retest

The engineering team triaged findings the morning after each daily critical-finding email. By the end of the engagement, all critical and high-severity findings had been fixed and retested. The launch shipped on the original date with no security blockers.

Beyond the engagement

A short executive summary in SOC 2 Type 1 Trust Service Criteria format was appended to the report on the client’s request — they were preparing for their first SOC 2 audit later in the year and wanted the audit findings to start from a documented baseline.