A redirect parameter sends visitors to any URL it is given
The older TLS versions parameter takes a destination and redirects to it without checking where it points.
Why it matters
The older TLS versions parameter takes a destination and redirects to it without checking where it points. We sent it `{PROBE_URL}` and the server answered `the value` with a Location header pointing at that address. The link an attacker sends therefore begins with your domain — it survives the check a person actually performs, and the check most mail filters perform — and lands on a page they control, under your brand and your certificate. That is the phishing case, and it is the smaller one. The larger one is that OAuth and SSO allow-lists are written as "redirect back to our domain". An open redirect ON that domain turns the allow-list into a pass-through, which is how an authorization code ends up at somebody else's server and an account is taken over without a password ever being entered.
How ShipReady detects it
Redirect parameters the site uses, probed with an off-site destination. SITE-scoped so a parameter appearing in a shared header or footer link is probed once for the whole crawl rather than once per page carrying it.
Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.0.0.
How to fix it
This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.
The affected parameter redirects to whatever URL it is given. Validate the destination server-side before redirecting — never trust the value as supplied.
The reliable rule is an ALLOW-LIST OF PATHS, not a check on the string. Accept only a relative path, reject anything else, and build the final URL yourself from your own origin plus that path. In Next.js: parse it with `new URL(value, request.nextUrl.origin)` and redirect only when the result's `origin` equals your own; otherwise fall back to a safe default like `/dashboard`.
Three string checks that look right and are not. `value.startsWith('/')` accepts `//evil.example`, which browsers treat as an absolute URL to that host — this is the single most common way the bug survives a fix. `value.includes('yourdomain.com')` accepts `https://evil.example/?x=yourdomain.com` and `https://yourdomain.com.evil.example`. A regex anchored on the start of the string still misses backslashes, encoded slashes (%2F%2F) and whitespace-prefixed values that browsers normalise away. Parse the URL; do not pattern-match it.
If the redirect is INTENTIONAL — a click tracker or a link shortener — the same fix applies in a different shape: keep an allow-list of permitted destination hosts, or sign the destination with an HMAC you verify before redirecting, so only URLs your own code generated are honoured.
Then check what else trusts your domain. OAuth and SSO redirect allow-lists written as "any URL on our domain" are bypassed by this, so review those entries and prefer exact callback URLs over wildcards.Frequently asked questions
- What does "A redirect parameter sends visitors to any URL it is given" mean?
- The older TLS versions parameter takes a destination and redirects to it without checking where it points.
- How serious is it?
- ShipReady rates this high. Fix before launch. A real weakness that an attacker can act on.
- How do I fix it?
- Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.
- Can I check my own site?
- Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.
Related checks
Run this check on your site
ShipReady checks this and 193 other things across up to ten pages of your site, with an AI-ready fix for each. Free, no signup.