Proteggere gli URI di redirect
Scopra perché la convalida degli URI di redirect è fondamentale per la sicurezza OAuth2 e come prevenire gli attacchi di open redirector e intercettazione del codice.
Proteggere gli URI di redirect è una lezione OAuth2 & OpenID Connect Deep Dive gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento OAuth2 & OpenID Connect Deep Dive, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso OAuth2 & OpenID Connect Deep Dive include 4 lezioni in totale.
Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.
The redirect_uri Is Critical
After the user authorizes, the authorization server sends the code (or token) back to the client by redirecting the browser to the redirect_uri. If an attacker can influence that URI, they can steal the code.
Redirect URI validation is therefore one of the highest-impact security controls in OAuth2.
Exact Matching
The single most important rule: the authorization server must compare the supplied redirect_uri against pre-registered values using exact string matching, not pattern or prefix matching.
Registered: https://app.example.com/callback
Request: https://app.example.com/callback (OK)
Request: https://app.example.com/callback/x (REJECT)Open Redirector Abuse
Loose matching enables open redirector attacks. If https://app.example.com/* is allowed, an attacker may target a page that bounces to an evil host, smuggling the authorization code out.
Wildcards Are Dangerous
Avoid wildcard subdomains and ports. Something like https://*.example.com/cb lets an attacker who controls any subdomain (including user-content subdomains) receive codes.
Always Require HTTPS
Redirect URIs must use https, except for native loopback (http://127.0.0.1) during local development. Plain http over the network exposes the code to interception.
Fragments and Query Tricks
Attackers add fragments (#) or extra query parameters to confuse parsers. Normalize and compare the full registered URI, and reject requests whose redirect_uri carries unexpected components.
Native App Schemes
Native apps often use custom schemes like myapp://callback, but these can be hijacked by another app registering the same scheme. Prefer claimed HTTPS redirects (Universal Links / App Links) which the OS verifies against your domain.
Validating on Both Requests
If a redirect_uri was sent in the authorization request, the same value must be sent at the token request and the server must verify they match. This binds the code to the original client and redirect.
POST /token
grant_type=authorization_code
&code=SplxlOBeZ
&redirect_uri=https://app.example.com/callback <-- must equal the one used earlierA Validation Helper
Server-side exact-match check, no normalization shortcuts:
function isAllowed(requested, registeredList) {
return registeredList.includes(requested);
}
// Reject anything not an exact, literal match.Combine With PKCE and State
Strict redirect validation pairs with PKCE (so a stolen code is useless without the verifier) and the state parameter (to bind the response to the session). Defense in depth keeps codes safe even if one control slips.
Operational Tips
Keep the registered redirect list short and reviewed. Remove staging URLs from production clients, audit them regularly, and never let users dynamically add arbitrary redirect URIs.
Quick Check
Test your redirect URI security knowledge.
Recap
Securing redirect URIs is foundational:
- Use exact-match registration; avoid wildcards and prefix matching.
- Require HTTPS (loopback excepted) and reject odd fragments/params.
- Re-validate redirect_uri at the token request.
- Combine with PKCE and state for defense in depth.
Impara OAuth2 & OpenID Connect Deep Dive con un tutor IA — gratis
Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.
- Corsi
- 12
- Lezioni
- 48
Domande Frequenti
La lezione «Proteggere gli URI di redirect» è gratuita?
Sì — il testo completo di «Proteggere gli URI di redirect» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso OAuth2 & OpenID Connect Deep Dive, passa a CoddyKit PRO. Il corso OAuth2 & OpenID Connect Deep Dive include 4 lezioni in totale.
Cosa imparerò in «Proteggere gli URI di redirect»?
Scopra perché la convalida degli URI di redirect è fondamentale per la sicurezza OAuth2 e come prevenire gli attacchi di open redirector e intercettazione del codice. Eserciti OAuth2 & OpenID Connect Deep Dive con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare OAuth2 & OpenID Connect Deep Dive?
Non è richiesta alcuna esperienza precedente. OAuth2 & OpenID Connect Deep Dive su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.
Quanto tempo richiede la lezione «Proteggere gli URI di redirect»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione OAuth2 & OpenID Connect Deep Dive?
Sì. Ogni lezione OAuth2 & OpenID Connect Deep Dive include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Sicurezza dei token (access/refresh)
- Parametro state e CSRF
- Best practice per i grant type
- Proteggere gli URI di redirect