Zabezpieczanie URI przekierowań
Dowiedz się, dlaczego walidacja URI przekierowania jest kluczowym elementem bezpieczeństwa OAuth2 oraz jak zapobiegać atakom typu open redirector i przechwytywaniu kodu.
Zabezpieczanie URI przekierowań to bezpłatna lekcja OAuth2 & OpenID Connect Deep Dive na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej OAuth2 & OpenID Connect Deep Dive, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs OAuth2 & OpenID Connect Deep Dive zawiera 4 lekcji w sumie.
Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.
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.
Często zadawane pytania
Czy lekcja „Zabezpieczanie URI przekierowań” jest bezpłatna?
Tak — pełny tekst „Zabezpieczanie URI przekierowań” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu OAuth2 & OpenID Connect Deep Dive, przejdź na CoddyKit PRO. Kurs OAuth2 & OpenID Connect Deep Dive zawiera 4 lekcji w sumie.
Co nauczysz się w „Zabezpieczanie URI przekierowań”?
Dowiedz się, dlaczego walidacja URI przekierowania jest kluczowym elementem bezpieczeństwa OAuth2 oraz jak zapobiegać atakom typu open redirector i przechwytywaniu kodu. Ćwiczysz OAuth2 & OpenID Connect Deep Dive z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć OAuth2 & OpenID Connect Deep Dive?
Nie wymagamy żadnego doświadczenia. OAuth2 & OpenID Connect Deep Dive w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.
Ile czasu zajmuje lekcja „Zabezpieczanie URI przekierowań”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji OAuth2 & OpenID Connect Deep Dive?
Tak. Każda lekcja OAuth2 & OpenID Connect Deep Dive zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Bezpieczeństwo tokenów (dostępu i odświeżania)
- Parametr state i CSRF
- Najlepsze praktyki dotyczące typów grantów
- Zabezpieczanie URI przekierowań