Wildcard redirect URIs registered with OAuth providers allow an attacker to redirect an authorization code to any subdomain they control — including user-generated content subdomains, preview deployments, or abandoned subdomains. CWE-601 (Open Redirect) is the direct failure; CAPEC-194 documents subdomain takeover-based OAuth redirect attacks. OWASP A01 (Broken Access Control) covers the authorization code interception that results. An authorization code delivered to the wrong endpoint is equivalent to handing the attacker a short-lived session credential.
Info because wildcard redirect URIs require a subdomain takeover or other coincident vulnerability to exploit, but the configuration defect itself is a low-effort fix.
Register exact redirect URIs in your OAuth provider's developer console — no wildcards, no trailing slash ambiguity:
# OAuth provider dashboard — Allowed redirect URIs
https://app.yourdomain.com/api/auth/callback/google
https://staging.yourdomain.com/api/auth/callback/google
If your application constructs the redirect URI dynamically, validate it against an explicit server-side allowlist before passing it to the provider:
const ALLOWED_REDIRECTS = [
'https://app.yourdomain.com/api/auth/callback/google',
'https://staging.yourdomain.com/api/auth/callback/google'
]
if (!ALLOWED_REDIRECTS.includes(redirectUri)) {
return Response.json({ error: 'Invalid redirect URI' }, { status: 400 })
}
Never accept redirect_uri from user-supplied query parameters without explicit allowlist validation.
ID: saas-authentication.social-auth.social-callback-whitelist
Severity: info
What to look for: Check the OAuth provider configuration (in the provider's developer console config, and in the application's auth configuration). Verify that the registered redirect/callback URIs are an explicit whitelist of your application domains, not wildcard patterns like https://*.yourdomain.com. Also check if your auth callback handler validates the redirect_uri before using it. Count every OAuth provider configured and enumerate each with its callback URL configuration. Report: X of Y providers have explicitly whitelisted callback URLs.
Pass criteria: The callback URL registered with OAuth providers is an explicit list of known domains (production, staging). No wildcard patterns in the registered URIs. The application does not accept a redirect_uri parameter from user input without validating it against a whitelist. At least 1 implementation must be confirmed.
Fail criteria: The registered callback URI uses wildcard subdomains, or the application allows user-controlled redirect_uri values without server-side whitelist validation.
Skip (N/A) when: (1) No OAuth integrations. Signal: no social auth providers in dependencies or config. (2) OAuth integrations are present but the callback URL whitelist is configured exclusively in the provider's external dashboard and is not inspectable from code.
Cross-reference: The oauth-state-validation check verifies the state parameter that prevents CSRF on the callback URLs whitelisted here.
Detail on fail: "Auth config registers OAuth callback as https://*.example.com/* — wildcard allows attacker-controlled subdomains as redirect targets" or "Auth callback handler accepts redirect_uri from query parameter without whitelist validation".
Remediation: Wildcard redirect URIs in OAuth configuration allow attackers to redirect the authorization code to attacker-controlled subdomains. Keep redirect URIs specific:
In your OAuth provider dashboard:
Allowed redirect URIs:
https://app.yourdomain.com/api/auth/callback/google
https://staging.yourdomain.com/api/auth/callback/google
In your application, if you dynamically construct the redirect URI, validate it against a server-side whitelist before using it. Never accept redirect_uri from request query parameters without explicit validation.