A development-time callback URL left in production Cognito app clients creates a token exfiltration endpoint that could allow attackers who control a localhost listener to steal tokens.

In Cognito’s authorization code flow, an attacker controlling the user’s localhost:3000 can intercept the authorization code and exchange it for tokens; in the implicit flow, tokens in the URL fragment can be captured by a localhost listener.

Scanner tools often flag individual issues but miss the dangerous compound pattern without cross-setting analysis that considers how configurations interact.

Fixing the vulnerability is quick—about 30 seconds—by removing development URLs, and the broader lesson is to assess cross-setting interactions rather than evaluating settings in isolation.

The piece references real-world bug bounty practices and demonstrates risks with a static analysis tool, grounding the issue in practical context.

Practical remediation steps include removing non-production HTTPS endpoints from callback URLs, eliminating localhost and HTTP callbacks, separating staging from production clients, enabling token revocation, shortening token lifetimes, and restricting scopes.

A compound risk exists where seemingly acceptable individual settings combine with open redirects, no revocation, long token lifetimes, implicit flow, and broad admin scopes to enable persistent privileged account takeover.

Five common callback URL mistakes are localhost entries, localhost wildcard patterns, wildcard HTTPS subdomains, HTTP callbacks, and staging callbacks left in production, each enabling token leakage in different scenarios.

Verification of remediation can be done with a script that enumerates Cognito clients, validates callback URLs, and flags localhost or non-HTTPS configurations.