Answer First
Definition: An open redirect is a link or forwarding rule that sends a visitor to a destination its owner did not intend. On a managed campaign subdomain, forwarding to an external URL is the normal mode of operation — spring-sale.brand.com exists to land on an outside landing page. What turns that entry into an open redirect is control: an unreviewed, ungoverned, or changeable destination is open for abuse.
Why: A subdomain on your brand’s domain carries trust the destination does not. Users, email filters, ad platforms, and security tooling treat brand.com links as yours. Every managed entry that points — or can be silently repointed — at an external URL lets an attacker borrow that trust: the address bar shows your domain while the page is theirs — the exact mechanism of credential phishing. The attacker does not need to compromise your subdomain, just one live, loosely governed entry.
Example: Marketing creates summer-launch.brand.com pointing at an agency-hosted landing page and gives the contractor edit access. The campaign ends, the entry stays live, the access never revoked. Months later the destination becomes a lookalike login page. A user clicks an old campaign link, sees summer-launch.brand.com in the address bar, and enters credentials — no infrastructure was hacked, only a forwarding entry left ungoverned.
Key Facts
- An open redirect transfers trust, not just traffic: the visible URL is your domain while the content is someone else’s — which is why CWE-601 flags phishing as its core consequence.
- On a managed forwarding product, an open redirect is not a bug; it is the feature. The risk is governed by who controls destinations and how visible changes are — not by removing the redirect.
- Attackers rarely hack the subdomain — the realistic paths are a changed destination, a forgotten entry from an ended campaign, or never-revoked credentials.
- Marketing-created entries widen the surface: more entries, faster publishing, distributed ownership, contractor churn, and deadline pressure that shortens review.
- Redirect type affects repointing speed: 301 responses can be cached by browsers, so a repointed 301 lingers; a 302 re-resolves per request, so changes take effect immediately.
| Attack pattern | How it plays out | Control that reduces it | | Silent repointing | A live entry’s destination changes after approval (stale account, ex-contractor, compromise) | Who-can-change permissions, change log, re-review on every change | | Abandoned live entry | A finished campaign keeps forwarding and the URL gets reused in phishing mail | Status visibility: pause or retire entries, review on a schedule | | Lookalike destination | An approved entry forwards to a similarly spelled, unrelated domain | Destination review at publish and on every change | | Entry sprawl | Many subdomains and entries with no named owner | Consolidation and ownership hygiene, as in our acquisition playbook |
Practical limits. These controls reduce risk; they do not make abuse impossible. PushULink does not scan destinations for phishing or malware — destination review is a human, point-in-time control, and a reviewed destination can later be repointed or go bad. Permissions narrow who can change an entry but do not undo a change already published; the change log is evidence, not prevention. A forwarding console also cannot fix the open-redirect bug in your own application code (unvalidated ?url= parameters, per OWASP) — that is fixed in code, not in a console. And no tool stops a legitimate, reviewed entry from being cited in a phishing email; that needs education and takedown response, not another setting.
Expert Explanation
How an open redirect works
When a browser requests a URL, a server can answer with a redirection status code (301, 302, 307, or 308, per RFC 9110) and a Location header naming the destination. The browser follows it automatically, and users rarely notice. OWASP describes the dynamic precisely: a crafted link redirects the user to a malicious site while the user believes they are on the trusted one.
Permanent versus temporary matters in a forwarding product. A 301 tells browsers and caches “this is the permanent home,” so the redirect can be cached and a later change may propagate slowly. A 302 re-resolves on every request, so a repointed 302 takes effect immediately. Neither is inherently safer; the trade-off is propagation speed and how search engines treat the entry, which we cover in the 301 vs 302 guide for campaign entries.
Why campaign subdomains are the target
A subdomain multiplies trust. launch.brand.com inherits the brand’s credibility with users and often technical privileges too — allow-listed in email security, trusted by ad review, permitted through corporate proxies. Attackers look for the cheapest way to mint that trust, and a forwarding entry is cheap — no takeover, no DNS compromise, no code. They just need a URL on your domain that forwards to a destination they influence. OWASP’s guidance — allow-listing destinations, mapping entries to fixed targets — applies equally to every entry in a forwarding console: the destination is the only thing that matters, and it must be controlled.
The managed-entry twist: the redirect is the feature
Shorteners and forwarding products are safe because the destination table is centrally controlled. An entry becomes “open” in the CWE-601 sense when its destination is an arbitrary external URL that anyone with access can change. Hardening a forwarding product means governing the destination — who sets it, who can change it, what state the entry is in, and what changed and when.
Why marketing-created entries widen the surface
Marketing creates campaign entries under deadline, often with agencies, contractors, or interns holding access. The entry’s lifecycle — live for a promotion, then stale — rarely matches the account lifecycle, which keeps working for years. Combined with sprawl from repeated campaigns and acquisitions, where teams inherit subdomains nobody owns, the result is a large, loosely governed surface. And a destination correct at publish can silently drift: the entry may forward exactly as configured while the landing page no longer matches what the ad promised. Every drift point is a repointing opportunity.
Decision Framework
Reduce the risk with four controls PushULink already exposes. None are new features; the discipline is applying them to every entry, at publish and on every change.
- Destination review. Treat the destination as the security boundary. Verify the hostname matches the campaign brief — exact domain, correct registrant, HTTPS — and be wary of similarly spelled domains. A change to a live entry is a new review, not a formality.
- Who-can-change permissions. Restrict edit rights to named roles and revoke access when the campaign or the person ends. Ask: who can change this entry’s destination six months from now? If the answer is “someone we no longer manage,” that is an open redirect.
- Status visibility. Make the status reflect reality: draft while under review, live only while the campaign runs, paused or retired when it ends. A stale “live” entry is an invitation; the status field is how you shut it off.
- The change log. Keep the record of who changed what and when — the difference between “we noticed a bad destination” and “we can prove what happened,” the evidence trail auditors and incident response want (see our entry management and compliance audits article).
Checklist — before an entry goes live and on every change:
- Destination hostname is exactly the intended domain (no lookalikes or misspellings).
- Destination serves over HTTPS.
- A named owner is recorded for the entry.
- Who-can-change is limited to named roles; stale access is revoked.
- Status matches reality, with a plan for when the campaign ends.
- Recent change-log entries have been reviewed for unexpected edits.
- Every destination change is reviewed as strictly as the original publish.
Key Takeaways
- On a forwarding product, an open redirect is the feature, not the bug — risk lives in who controls destinations and how visible changes are.
- Attackers don’t compromise branded subdomains; they find one live, loosely governed entry and repoint it.
- Four controls reduce the surface: review, permissions, status, and the change log.
- The 301 vs 302 choice determines how fast a repoint propagates; know which you use and why.
- Review is point-in-time and human — pair it with access revocation, status hygiene, and the change log.
FAQ
Q: What is an open redirect in plain terms?
A: A link that forwards from one site to another. It becomes an “open redirect” when the destination is attacker-influenced: the visible URL stays on the trusted domain, so a phishing link routed through it looks legitimate. CWE-601 lists it as a weakness for exactly this reason — the server name in the modified link is identical to the original site.
Q: Isn’t every entry on a managed subdomain an open redirect?
A: Technically yes — every entry forwards to an arbitrary destination, and that is the product’s job. What separates a safe managed redirector from an open redirect is control: destinations that are reviewed, owned, permissioned, and traceable. A forwarding product becomes “open” in the dangerous sense when destinations are ungoverned, not because redirects exist.
Q: If we review the destination at publish time, can the entry still be abused?
A: Yes. Review is point-in-time: a destination that was correct at publish can be changed later — the ad was approved, but the landing page changed — or the destination site itself can be compromised. That is why re-review on change, restricted permissions, and the change log matter as much as the initial approval.
Q: Does PushULink automatically block phishing destinations?
A: No. PushULink does not scan or block destinations automatically; it exposes the controls — destination review, permissions, status visibility, and the change log — so your team applies its own review and oversight. Treat any claim of automatic malicious-destination blocking as a feature to verify, not a product guarantee.
Sources
- OWASP Cheat Sheet Series — “Unvalidated Redirects and Forwards”: defines the attack class and its mitigations. https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html
- MITRE CWE-601 — “URL Redirection to Untrusted Site (‘Open Redirect’)”: the canonical weakness entry, with phishing and credential-theft consequences. https://cwe.mitre.org/data/definitions/601.html
- RFC 9110 — HTTP Semantics, §10.2.2 (Location) and §15.4 (redirection status codes): redirection status code mechanics. https://www.rfc-editor.org/rfc/rfc9110
- MDN — “Redirections in HTTP”: permanent vs. temporary redirects and browser caching. https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections