# How to Audit Redirect Chains After a Domain or HTTPS Migration

Canonical: https://vulnify.app/blog/audit-redirect-chains-domain-https-migration

Learn how to audit redirect chains after a domain, CDN, hosting, or HTTPS migration, find unnecessary hops and insecure transitions, and document a clean redirect baseline.

Redirects are one of the easiest parts of a migration to underestimate. A site can appear to work while users, search engines, security scanners, and API clients take very different paths to the final destination. Old hostnames, HTTP-to-HTTPS upgrades, trailing-slash rules, language redirects, CDN normalization, and application-level routing can combine into long chains or loops that nobody intended. Redirect problems are usually discussed as an SEO or performance issue, but they can also affect security. An insecure HTTP hop, an unexpected cross-domain destination, a stale legacy host, or a redirect rule that behaves differently for selected paths can create confusion around authentication, cookie scope, canonical URLs, and public attack surface. This tutorial provides a practical way to review the entire chain after a domain, CDN, framework, or HTTPS migration. What is a redirect chain? A redirect chain occurs when one URL redirects to another, which redirects again before the browser reaches the final response. A simple migration might look like this: http://example.com -> https://example.com -> https://www.example.com/ -> https://www.example.com/home Each step may be individually valid, but the combined path creates extra requests and additional configuration states to maintain. A cleaner design usually sends common entry points directly to one canonical HTTPS destination. Why redirect chains appear after migrations The old host redirects HTTP to HTTPS before forwarding to the new domain. A CDN normalizes the hostname while the application separately normalizes paths. The web server adds or removes a trailing slash and the framework reverses it. Legacy rewrite rules remain active after a platform migration. Internationalization middleware redirects again after the canonical host changes. Authentication software adds a return URL or login redirect on top of infrastructure redirects. Old marketing links point through tracking or campaign URLs. The problem is often ownership. DNS, CDN, reverse proxy, application framework, and CMS each have the ability to redirect, so one team may not see the entire chain. Security concerns hidden inside redirect chains Unexpected HTTP hops A migration should not send a user from HTTPS back to HTTP and then to HTTPS again. An insecure intermediate hop can weaken transport assumptions and may expose information in environments where HSTS is not already active. Review the complete chain rather than checking only the final page. Unexpected cross-domain hops A redirect to a different hostname may be legitimate, but it deserves attention around login, payment, password reset, and account flows. Cookies, referrer data, OAuth state, and allowlisted callback URLs can behave differently when the host changes. Legacy origin exposure An old hostname may continue serving content instead of redirecting consistently. That can leave a forgotten version of the application reachable with weaker headers, older software, or a different authentication path. Do not confuse long chains with open redirects A long redirect chain is not automatically an open redirect vulnerability. Open redirects involve attacker influence over the destination. Chain auditing is about understanding every hop and ensuring each destination is intentional. If a route accepts values such as next , returnUrl , or continue , review that behavior separately and restrict destinations appropriately. Understand the redirect status codes you are using HTTP provides several redirect status codes. The right choice depends on whether the change is permanent and whether the client should preserve the request method. Teams should understand the behavior of 301 , 302 , 307 , and 308 rather than treating them as interchangeable. For ordinary website canonicalization, the important operational goal is consistency. Avoid one layer returning a temporary redirect while another returns a permanent redirect for the same migration rule unless there is a deliberate reason. Hypothetical scenario: four layers redirect the same request A company migrates from old.example.com to www.example.com and enables a CDN. The old Nginx server redirects HTTP to HTTPS. The CDN redirects the old hostname to the new hostname. The application adds a trailing slash, and the CMS redirects /home/ to / . A visitor using an old bookmark now makes four requests before reaching the homepage. During the migration, one API route skips the CDN rule and continues to serve from the old origin. The marketing pages look correct, but the public attack surface now includes a legacy host that the team thought had been retired. The fix is to define one canonical target for each legacy entry point, move redirection as close to the edge as practical, remove redundant application rules, and explicitly retire the old origin once traffic has been validated. How to audit a redirect chain step by step 1. List the entry points users may still reach Include HTTP and HTTPS, apex and www , old domains, common legacy paths, campaign URLs, and important subdomains. Do not test only the canonical homepage. 2. Follow every hop Use the Vulnify Redirect Chain Checker to see hop-by-hop evidence, loops, downgrade behavior, and canonical-path issues. Record the status code and destination of each step. You can also inspect a specific path from a terminal during authorized troubleshooting: curl -I http://example.com/old-path curl -I https://example.com/old-path Remember that a single -I request shows one response. Use appropriate tooling when you need to follow the entire chain and preserve evidence for each hop. 3. Check HTTPS and certificate behavior Every hostname that remains in the redirect path may still need a valid certificate because the client must establish HTTPS before receiving an HTTPS redirect. Use the SSL Checker on important legacy and canonical hosts. 4. Review HSTS If HSTS is enabled, confirm the policy matches the migration architecture. A parent-domain includeSubDomains rule can affect legacy hosts before they redirect. Use the HSTS Checker to validate the public policy. 5. Test representative paths, not just / Test login, account recovery, checkout, APIs, old content paths, language routes, and errors. Redirect rules often differ by location block or application route. 6. Collapse redundant hops Where practical, redirect directly from each legacy entry point to the final canonical destination. This reduces latency and removes intermediate states that can drift later. 7. Retest after cache and CDN changes Redirects can be cached aggressively. A corrected origin rule may not be visible immediately at the edge. Purge or expire caches according to your platform and verify from the public hostname. Be careful around authentication redirects Login flows often contain several intentional redirects between an application and an identity provider. Do not simplify them blindly. Instead, verify that callback destinations are exact, state values are validated by the application, and return URLs cannot be changed to arbitrary external destinations. When a migration changes hostnames, update identity-provider redirect URIs deliberately. Temporary wildcard callbacks can become permanent security debt if nobody removes them later. Check cookie scope when hostnames change A migration from app.example.com to www.example.com may change which cookies are sent based on Domain and Path attributes. Redirects themselves do not fix cookie scope. Review authenticated workflows after the final hostname is selected and use the Cookie Security Checker for public cookie attributes. Monitor the canonical path after launch Redirects can regress after CDN changes, CMS updates, or DNS migrations. A broader Website Security Scanner can review redirects alongside other supported public-surface checks. If the origin is operationally important, ongoing monitoring can help detect changes between deeper reviews. Redirect-chain audit checklist Test HTTP and HTTPS entry points. Test apex, www , and legacy hostnames. Record each status code and destination. Remove unexpected HTTP downgrade hops. Validate certificates on redirecting HTTPS hosts. Check HSTS before retiring or changing subdomains. Test important paths, not only the homepage. Review authentication callbacks and return URLs. Check cookie scope after hostname changes. Collapse redundant redirects. Retest after CDN and cache updates. Capture a redirect baseline before migration If a migration is planned, record representative redirect behavior before the cutover. Include the homepage, common deep links, legacy URLs with known redirects, login and logout endpoints, HTTP and HTTPS variants, and important marketing URLs. A baseline makes it easier to distinguish intentional architectural changes from accidental redirect regressions. After cutover, compare status codes, destinations, hostname changes, and the number of hops. A one-hop permanent redirect may become three temporary redirects after a CDN and load balancer are introduced. Even if the final page loads, the added complexity can affect latency, caching, SEO, cookie scope, HSTS behavior, and troubleshooting. Record the chain as evidence For important routes, keep a simple record of the source URL, each intermediate response, the final destination, and the reason the redirect exists. This is especially valuable for authentication and payment flows where redirects cross trust boundaries. When a later change introduces an unexpected hop, the team has a known-good comparison rather than relying on memory. Conclusion A successful migration is not just a site that eventually reaches the right page. The path should be intentional, secure, and easy to explain. Map every important entry point, follow every hop, eliminate downgrade behavior and redundant redirects, verify TLS and HSTS on participating hosts, and test authentication and cookie behavior after hostname changes. Fewer, clearer redirect rules reduce both operational surprises and public attack-surface drift.