You cannot simply publicly access private secure links, can you?

Security model of “private” links

• Many commenters argue that links with unguessable tokens but no access control are just “security by obscurity.” They’re not inherently private; they’re only hard to brute-force.
• Others stress that obscurity can be acceptable as one layer in “security with obscurity,” but must not be the only protection.

Why secrets in URLs leak

• URLs get logged in browser history, server access logs, reverse proxies, CDNs, firewall/IDS logs, and link scanners. Password fields and POST bodies often don’t.
• Messaging and email platforms, security gateways, and URL-scanning services automatically fetch links for previews or malware checks, unintentionally exposing “magic links” and even downloaded files.
• Non-E2EE channels mean the platform sees all links; users often don’t realize this.

Comparing links vs passwords

• Theoretically a long random URL token can have far more entropy than a password and is effectively unbrute-forceable.
• Practically, passwords are treated as sensitive by tools and users; URLs are routinely stored, shared, and indexed.
• Links are “something you have” and are easily copied; passwords are “something you know,” at least in principle.

Legitimate uses of tokens in URLs

• Short-lived, single-use tokens for password resets, email verification, S3 presigned URLs, and similar flows are widely accepted.
• Some media access patterns (CDN-hosted images, WebSockets without cookies, binary caches) often rely on URL tokens out of necessity or convenience.

Mitigations and better patterns

• Recommended mitigations: very short expiry, single use, per-user tokens, revocation, rate limiting, and avoiding long-lived “infinite use” magic links.
• Prefer auth in headers/cookies or POST bodies; avoid persistent secrets in query strings or paths.
• Using URL fragments for secrets keeps them off the wire, but only works with client-side logic and still risks JS exfiltration and browser history leakage.
• Some suggest schemes or headers to tag URLs as “private,” but others note attackers and some scanners would simply ignore such tags.

Scanning tools, UX, and responsibility

• Debate over who’s responsible: services that publicly index scanned URLs, email/messaging platforms that auto-submit links, or developers who encode auth into URLs.
• Several call out poor UX: scan tools that default to public results without clearly warning users, or ambiguous labels like “public scan” and “report.”