[couchand]

Indeed, the only valid operation with the magic URL is exchanging the URL-based token with something else (your PDF, a session token, etc.) and then expiring the URL, so by the time the scanner gets around to it the original URL is invalid.

[ta1243]

That seems ripe for race condition class problems.

[couchand]

If anybody but the intended recipient gets the magic URL first there's something more critical wrong with some assumption in your authentication scheme.

[fragmede]

In the war against malware on the web, messenger services like Facebook messenger and google chat have been known to visit links passed through their service. the attacker hijacks an account, and then sends the malware link to all of that users contacts. coming from a trusted source, those contacts visit the link, and they get their account hijacked, and the cycle continues. in order to combat this, the platforms will visit the link to verify it isn't malware. Thus, the platform has the magic url. We trust them not to abuse this privilege, but that's one case where someone other than the intended recipient has the magic url.

[couchand]

You describe a very real problem, but from what I can tell it's an entirely disjoint context. I'm honestly not clear what the scenario you're suggesting is. Your platform would send an authenticated URL to a verified user over a verified communications channel. There may be applications where the channel of choice is a social media service, but I'm having a hard time seeing why you support that but not support the bog standard OAuth flow for that provider?

Or are you just saying, sometimes a user will receive their authenticated URL on the verified channel and then self-leak it on another channel? In which case, it really doesn't matter what that other channel is...