Routing links and phishing
Any service that forwards a tap to an arbitrary destination is one configuration mistake away from being an attack tool.
6 August 2026 ยท PAD team
The mechanism
A routing link takes a destination and sends visitors there. If the destination can be anything, the service is an open redirect: an attacker puts a trusted domain in front of a malicious page, and filters that trust the domain let it through.
This is not theoretical. Open redirects on reputable domains are actively hunted and abused within days of being discovered.
What a responsible service restricts
- Destinations limited to app stores and known attribution providers by default
- Arbitrary destinations only after the domain is verified as yours
- Verification by a file you upload, proving control of the domain
- No user-supplied destination in the URL itself, ever
That last point matters most. If a service accepts ?url= in the address, anyone can point it anywhere without an account.
Our own arrangement
Destinations are restricted to store URLs and attribution links until you verify your domain by uploading a file to it. Only then can your own pages be a destination. Without that restriction the service would be abused for phishing within a day of launch, which is why the limitation exists rather than being an oversight.
What to ask a vendor
- Can a destination be set without owning the domain?
- Is the destination ever taken from the URL rather than from an account?
- What happens if a link is reported as malicious?
- Are links disabled when an account is suspended?
The trade being made
Restrictions are friction. A service with no restrictions is easier to start with and will eventually be blocked by spam filters and platforms once it has been abused, taking every legitimate link on it down as well.
Ours restricts destinations to stores and trackers until you verify your own domain.