Redirect Chain Security Analyzer

Follow a redirect chain hop by hop and see HTTPS downgrades, cross-domain jumps, credential-carrying URLs, caching problems and excessive hops in one diagram.

Passive public check

a2z.tools reads publicly visible information from the address you enter. It is a read-only request - nothing is submitted, changed or probed.

URL to follow Starts on HTTP unless you give a scheme, because the HTTP entry point is where downgrades show up. Every hop is revalidated before it is followed.

Why the chain matters and not just the destination

Almost every link anyone follows goes through at least one redirect: HTTP to HTTPS, apex to www, an old path to a new one, a shortener, a sign-in provider and back. Each of those is a separate request, and a chain is only as secure as its weakest hop.

Checking the final URL tells you nothing about the journey. A chain that ends on a perfectly configured HTTPS page can still have passed through plain HTTP in the middle, and everything at that moment - the request, the response, and any cookie without Secure - was readable and modifiable by anyone on the network path.

What this reports

HTTPS downgrade. Any hop going from https to http. This is the finding worth the tool existing: it is invisible if you only look at where you ended up, and it silently undoes the protection of everything after it.
Cross-host hops. Not wrong in itself - sign-in and payment flows cross hosts constantly - but worth confirming you recognise every host in the list. A chain passing through an unexpected domain is what an abused open redirect looks like from the outside.
Credentials and tokens in URLs. A user:pass@ in a hop, or a redirect target carrying something that looks like a token in its query string. Query strings are written to server logs, proxy logs and browser history, and sent onward in the Referer header of whatever the destination page loads. The tool names the pattern and deliberately does not print the value.
Chain length. Every hop is a round trip the visitor waits for. Long chains usually mean two or three redirect rules each solving part of the problem, and can normally be collapsed into one.
Dead ends. A chain that resolves to a 4xx or 5xx. Whatever linked there is effectively broken.

Why it starts on HTTP

If you enter a bare domain, the tool starts at http:// rather than https://. That is deliberate: the plain HTTP entry point is where downgrade and redirect-loop problems actually live, and starting on HTTPS would skip the hop most worth looking at. Enter a full URL with a scheme if you want to start somewhere specific.

How the chain is followed safely

Following redirects on someone else's behalf is a classic server-side request forgery vector: the first URL looks harmless, and a redirect points somewhere internal. This tool revalidates every hop before following it, resolving DNS each time and refusing loopback, private, link-local, carrier-grade NAT and cloud metadata addresses. Re-checking per hop rather than once at the start is what defeats DNS rebinding, where a name resolves publicly the first time and internally the second.

The chain is also bounded - a limited number of hops, a byte ceiling and an overall timeout - so a redirect loop is reported rather than followed forever. Only GET is used, no credentials or cookies are ever forwarded, and nothing is submitted.

Fixing what it finds

For a downgrade, make every hop HTTPS and then add HSTS so browsers stop attempting HTTP at all. For a long chain, collapse the rules so the first request lands on the final URL - redirect to the canonical host and scheme in a single step rather than chaining a scheme rule into a host rule into a path rule. For tokens in query strings, move the value into a POST body or a fragment, or exchange it for a short-lived code at the destination.

Related: HTTPS Redirect Checker for the entry point alone, and HTTP Status Checker for a single URL.

Frequently asked questions

Is a redirect chain bad?

No. Redirects are normal and necessary. What matters is that no hop downgrades to plain HTTP, that you recognise every host involved, and that the chain is not longer than the job requires.

Why does it say my chain crosses several hosts when I only have one site?

Usually apex to www, or a CDN edge in front of your origin. Both are expected. The finding is informational and exists so an unexpected host in the list is visible, not because crossing hosts is itself a problem.

Will this follow a redirect to an internal address?

No. Every hop is revalidated before it is followed - DNS resolved again, and private, loopback, link-local and cloud metadata addresses refused. Re-checking each hop rather than only the first is specifically what stops DNS rebinding.

It flagged a token in my URL, but that value is not secret.

The check matches on the parameter name - token, access_token, session, api_key - not on the value, which it never inspects or prints. It is a prompt to look, not a claim that the value is sensitive.

References

Related tools

What this tool can and cannot tell you. It reports the configuration a site exposes to an ordinary visitor. It does not log in, submit anything, or test for vulnerabilities, so a passing result means the public configuration looked correct at the moment of the check - not that the site is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.