How SlaySlop checks Open Redirects

What an attacker sees on the public surface includes redirect targets that accept user-controlled destinations. Fancy login UX does not travel with that Location header. The browser only follows what the live endpoint returns.

SlaySlop publishes one sentence for Open redirects: it "Checks whether redirects can be steered to untrusted destinations." I treat that as a public-surface observation with evidence, not as a claim that every auth flow was fuzzed end to end.

Outcome the check is for

You get a Security finding when observed redirects appear steerable toward untrusted destinations. The outcome is a route-linked finding with evidence, ranked by impact among other verified findings. It is not a certificate that "our OAuth works in Chrome."

In the catalog this check lives under Security, beside CORS misconfiguration, Exposed files and admin panels, and related public-surface controls. The Security and secrets product describes the wider pass as headers, TLS, known vulnerabilities, client-bundle secrets, and public threat signals. Keep open redirects in the "public navigation can leave your trust boundary" bucket when you triage.

Boundaries

Read-only. Public surface. Permission required. SlaySlop does not edit code, content, settings, or data on the target. Scanning a site you do not own, manage, or have permission to test violates Acceptable Use. This is hygiene on a public attack surface, not a pentest, not an exploit walkthrough, and not permission to phish with someone else's brand.

The check is also not a claim about every deep link, every mobile deep-link bridge, or every marketing shortener behind a partner CDN. Product language is whether redirects can be steered to untrusted destinations. I read that as observed public redirect behavior that accepts destinations outside a safe allowlist or pattern, rather than "any 302 anywhere."

Happy path: how the signal is observed

Published scanner workflow, adapted to this check:

1. Open or request the public URL in the crawl context (real browser crawl for the site map; follow public redirects the scan can see).
2. Observe redirect responses and destination control on routes that accept next/return/continue style parameters or similar patterns.
3. Flag behavior that indicates an untrusted destination can be selected.
4. Attach findings with the evidence that triggered them.
5. Rank by impact so a login handoff redirect does not hide under a harmless marketing hop.

When I reproduce locally on a host I am allowed to test, I mirror the same idea with a destination I control that is clearly outside the site's allowlist:

# Permissioned host only. Observe Location; do not weaponize.
BASE="https://app.example.com/login"
curl -sI "$BASE?next=https://untrusted.example/land" \
  | awk 'BEGIN{IGNORECASE=1} /^HTTP|^location:|^cache-control:/{print}'

HTTP/2 302
location: https://untrusted.example/land

That shape is the concrete signal I care about. A redirect that always lands on a fixed relative path inside the same origin is a different shape. A hop that only accepts relative paths or a hard allowlist of partner hosts is also different. Read the finding's evidence before you rewrite every ?next= in the monorepo.

Pitfalls when reading the row

"Works from our marketing site" is not the same as "safe when an outsider picks the destination." Your marketing site is inside the trust story you tell users. The check asks whether redirects can be steered to untrusted destinations.

A single curl against the homepage also misleads. Open-redirect issues often live on login, SSO callback, password-reset continue links, or legacy language switchers—not on /. Look at the evidence URL, not only at the apex response.

Do not collapse this into Redirect chain. Redirect chain "Maps public redirects between the entered URL and final page." That is hop mapping and latency/SEO noise. Open redirects asks about destination control. Two different checks. One Security category for the steerability question.

What I write in the triage note

I paste the evidence URL, the observed Location, and whether the destination looked allowlisted. I name the owning service (auth, marketing CMS, CDN edge rule). I refuse to close the ticket with "browser blocked it once on my laptop." What the public surface returns is the story. Soft next step: if you already run SlaySlop on the host, re-open the Open redirects row after the allowlist lands and confirm the same evidence is gone.