Common Open Redirects mistakes that still ship

I have cleaned too many thin handoff pages that say "redirects OK" with no route list and no Destination policy. Crawlers and answer engines are not the only readers who notice missing context. Security reviewers notice too, usually on a worse timeline.

SlaySlop's Open redirects check "Checks whether redirects can be steered to untrusted destinations." The mistakes below fight that observation point: public surface, real redirect responses, evidence on the affected URL.

Outcome if you catch these early

You ship with an explicit destination policy on continue-style parameters, plus tickets that name routes instead of "fix redirects somehow." Metadata for humans on the security call matters as much as title tags for crawlers. Same discipline, different field.

Boundaries

Read-only public scan. Permission required. Not a pentest. Open redirects sits under Security. Closing this finding does not retire a Redirect chain mess or a CORS grant. Different signals.

Mistake: relative-path tests that never leave the origin

Someone tries ?next=/app and sees a same-host 302. They mark the ticket done. Absolute external destinations never get a probe. Production still accepts https://untrusted.example. The staging test was incomplete, not wrong. Incomplete tests are how thin security pages get published.

# Permissioned contrast on a host you control
U="https://app.example.com/login"
curl -sI "$U?next=/dashboard" | awk 'BEGIN{IGNORECASE=1} /^HTTP|^location:/{print}'
curl -sI "$U?next=https://untrusted.example" | awk 'BEGIN{IGNORECASE=1} /^HTTP|^location:/{print}'

Both probes belong in the same PR description. One without the other is a partial story.

Mistake: "the framework handles it"

Many frameworks offer helpers. Teams assume the helper is wired on every entry point. Legacy PHP bridges, custom SSO glue, and marketing landers often bypass the helper. The catalog check observes the live response, not the README claim. If the evidence shows an open Location, the framework story lost.

Mistake: homepage glance as auth proof

The apex URL returns 200. Login continues live on /auth/callback or /session/return. A glance at / never loads those handlers. SEO folks know better than to judge a site by one title tag; security folks should know better than to judge redirects by one homepage.

Mistake: conflating Redirect chain with Open redirects

Redirect chain "Maps public redirects between the entered URL and final page." Long chains hurt performance and confuse crawlers. They are not the same as destination steerability. You can have a clean two-hop HTTPS upgrade and still accept an untrusted next. You can have a five-hop mess with a locked allowlist. Fix the finding you actually have. Write the ticket title so search and humans can parse it: "Open redirects on /login next=" beats "redirects weird."

Mistake: allowlist in code, open rule at the edge

App code rejects external destinations. The CDN or API gateway still has a legacy redirect rule that trusts a query parameter. Scanners see the edge. Your unit tests see the app. Align them before handoff, or the Open redirects row will keep coming back after "we already fixed it."

What good looks like in the doc

A scannable block: parameter names, policy, owning service, verification commands, last rescan. No keyword stuffing. No "comprehensive redirect posture." Concrete beats promotional. If SlaySlop already watches the host, link the quiet Security row after the fix and move on.