Fix guide · high · oauth_redirect_uri_http

OAuth redirect_uri uses http:// (not HTTPS)

Why it matters

OAuth's authorization-code flow finishes by redirecting the user's browser to your redirect_uri with the auth code attached as a query parameter. If that URL is http://, the entire redirect — including the code — travels over plaintext. Any party on the network path (cafe wifi, ISP, transit network, employer proxy) can read the code in flight.

An auth code is single-use, but a TLS-stripped attacker only needs to *race* your legitimate backend to the token endpoint. They use the code first, exchange it for an access token, and your user's request fails — usually with a "session expired, please try again" UX that nobody investigates.

This is unconditionally a bug. There is no production scenario where http:// is correct for an OAuth callback. Localhost gets a special exception (the request never leaves the loopback interface) but every public deploy must be HTTPS.

How to fix it

1. Update your OAuth provider's allowlist to use the https:// form of your callback URL.
2. Update the redirect_uri parameter in your authorize URL to match.
3. Remove the http:// entry from the provider allowlist entirely — leaving it there means any future code path that builds the authorize URL incorrectly will still work, hiding the regression.
4. Force HTTPS on your domain. HSTS preload, redirect all http→https at the edge, and never serve content on port 80 in production.
5. For local development, use http://localhost (NOT http://0.0.0.0 or http://your-laptop.local) — most OAuth providers special-case localhost as exempt from the HTTPS requirement.

This finding is high severity, not critical, only because the auth code is single-use and short-lived (typically 60s). Realized impact requires an attacker on the network path *and* a race against the legitimate backend. But the fix is two clicks at the provider.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.