Native auth flow testing for Supabase and Firebase

Authentication is the front door of every application. If it's broken, nothing else matters — your authorization checks, your row-level security policies, your API rate limits all depend on the auth layer correctly identifying who is making the request. Yet most security scanners treat auth as a black box, logging in with a cookie and hoping for the best.

BrokenApp ships with native support for Supabase (GoTrue) and Firebase (Identity Toolkit) authentication. Instead of simulating login through a browser, the scanner talks directly to the auth provider's API, testing five specific failure modes that represent the most common auth vulnerabilities in modern stacks.

The five auth test cases

Every BrokenApp auth scan executes the same five tests, regardless of whether the target uses Supabase or Firebase. Each test maps to a specific CWE and validates a distinct property of the auth implementation.

Login success — the scanner authenticates with valid credentials and verifies that a valid session token is returned. This baseline test confirms the scanner can establish an authenticated session for the rest of the scan. A failure here indicates misconfigured credentials or a broken auth endpoint (CWE-287: Improper Authentication).

Login failure — the scanner sends invalid credentials and verifies the server rejects them with an appropriate error response. This test catches applications that return 200 status codes for failed logins, applications that leak user existence through differential error messages, and applications that don't rate-limit failed attempts (CWE-307: Improper Restriction of Excessive Authentication Attempts).

Session persistence — after a successful login, the scanner waits for a configurable interval, then attempts to use the session token to access a protected resource. This validates that sessions remain valid for their expected lifetime and that the application doesn't have overly aggressive session expiration that breaks legitimate usage (CWE-613: Insufficient Session Expiration).

Token refresh — the scanner uses the refresh token to obtain a new access token and verifies the new token grants the same access as the original. This test catches broken refresh flows where the new token has different permissions, missing claims, or an invalid signature (CWE-384: Session Fixation).

Logout invalidation — the scanner logs out, then attempts to use the previous access token to access a protected resource. If the server still accepts the revoked token, the scanner flags a session invalidation failure. This is one of the most commonly missed auth bugs — applications that use stateless JWTs without a revocation list will almost always fail this test (CWE-613: Insufficient Session Expiration).

How BrokenApp talks to GoTrue and Identity Toolkit

For Supabase targets, BrokenApp sends requests directly to the GoTrue API at your project's auth endpoint. It uses the /auth/v1/token?grant_type=password endpoint for login, /auth/v1/token?grant_type=refresh_token for refresh, and /auth/v1/logout for session revocation. The scanner sends your project's anon key as the apikey header, matching exactly how your frontend client communicates with Supabase.

For Firebase targets, BrokenApp uses the Identity Toolkit REST API. It authenticates via verifyPassword, refreshes tokens through the secure token endpoint, and validates session state by calling protected Cloud Functions or Firestore rules with the obtained ID token. The scanner handles Firebase's API key authentication and the exchange between ID tokens and refresh tokens natively.

This native integration means BrokenApp doesn't need to drive a browser to test auth. It communicates directly at the API layer, which is faster, more reliable, and catches issues that browser-based testing would mask — such as a frontend that silently retries failed requests or caches tokens locally.

TOML configuration

Auth testing is configured in your brokenapp.toml file. The scanner auto-detects the auth provider from your application's network requests during the crawl, but you can also configure it explicitly.

For Firebase, swap the provider and supply your Firebase API key and project ID instead. The test suite remains identical — only the underlying API transport changes.

Session health monitoring during scans

Auth testing doesn't stop after the initial five tests. Throughout the remainder of the scan, BrokenApp continuously monitors session health. Every request includes the authenticated session token, and the scanner tracks the response status codes. If the session is unexpectedly invalidated mid-scan — due to server-side timeout, token rotation, or a concurrent logout — the scanner detects the failure and attempts to re-authenticate.

This monitoring also catches a subtle class of bug: applications that invalidate sessions during normal usage. If browsing to a specific route causes the session to be destroyed, or if a particular API call rotates the token without returning the new one, the scanner flags the endpoint that caused the session disruption.

CWE mappings for auth failures

Every auth finding is mapped to a specific CWE identifier, making it straightforward to track remediation and integrate with compliance workflows. The mappings are: CWE-287 for authentication bypass, CWE-307 for missing brute-force protection, CWE-384 for session fixation during token refresh, and CWE-613 for insufficient session expiration or missing logout invalidation.

These CWE references are included in the JSON report, the SARIF export, and any GitHub issues created from the scan. They provide a standardized reference point for triaging findings and communicating severity to stakeholders who need to map vulnerabilities to compliance frameworks like SOC 2 or OWASP Top 10.