"A secret URL isn't real security" — what that objection gets right, and where it stops

Ask almost any AI assistant how to send someone an HTML page privately and you will get a version of this warning:

Simply uploading to an obscure URL is not genuinely private. Anyone who gets the URL can access it. If this is confidential, use actual authentication rather than relying on a secret URL.

It is good instinct, and it is repeated so consistently that it is worth answering properly rather than waving away. The sentence contains one claim that is true and load-bearing, and one that is a category error.

The part that is true

An unguessable link is a bearer credential. Possession is the whole of the authorisation. The server that hands out the page has no idea whether the person asking is the client you sent it to, a colleague they forwarded it to, or someone reading it off a screenshot.

Everything uncomfortable about the model follows from that single property, and none of it can be engineered away while keeping the thing that makes the model useful — that the recipient does not need an account.

The part that is a category error

"Security through obscurity" has a specific meaning: the system is safe only as long as nobody understands how it is built. Hide the algorithm, hide the file layout, hope nobody looks. It is a bad idea because understanding is cheap and, once someone has it, the protection is simply gone.

A random URL is not that. Everything about the design is public — you can read the format, you can read this paragraph explaining it. The only secret is a value drawn at random, which is precisely the structure of a password.

The number matters here, because it is the difference between the two arguments:

• A 32-character identifier drawn from 62 possible characters has 62³² combinations — around 2×10⁵⁷, roughly 190 bits of entropy.
• For comparison, a 12-character random password from the same alphabet is about 71 bits, and that is already considered strong.

There is no guessing strategy at 190 bits. Not a slow one, not an expensive one. This is why the pattern has a proper name in the literature — a capability URL — and why it is quietly load-bearing across software you already trust:

• Password reset emails. The link in one is the credential; clicking it proves nothing about identity except that you received the mail.
• Calendar invitations and video-call links. Anyone with the URL joins.
• Pre-signed cloud storage URLs (S3 and every service modelled on it) — a time-boxed capability handed to someone with no account on your infrastructure.
• "Anyone with the link" sharing in every mainstream document tool.
• Unsubscribe links, which authorise a change to your account with no login at all.

So the honest framing is not "unguessable links are insecure". It is: a capability URL is a real primitive with real, specific limits. Those limits are the useful conversation.

The four things it genuinely does not cover

None of these are about guessing, which is why "make the link longer" answers none of them.

1. Forwarding. The link travels with whoever holds it. If your reviewer sends it to a colleague, the colleague gets in. The link cannot object because it never knew who you meant in the first place.

2. Shared devices and browser history. A URL persists in history, in autocomplete, in a synced browser profile. On a machine several people use, "private" has quietly become "private until someone types the first three letters into the address bar".

3. Leakage to third parties. If the page loads scripts, fonts, or images from other services, its address can travel outward in a Referer header or an analytics payload. This is a real property of capability URLs and the reason the pattern gets criticised in security writing — worth checking on any host, including this one, if the page is genuinely sensitive.

4. No accountability, and no partial revocation. A shared secret proves somebody had the secret. It cannot tell you which person opened the page, and it cannot cut off one recipient without invalidating the link for everyone. If either of those has to be possible, you have outgrown the model — not because it is weak, but because it is answering a different question.

Where you should stop and use a login

This is the part the AI warning gets right, and it deserves a plain answer rather than a defensive one. Reach for an identity-backed gate — SSO, Cloudflare Access, a host with team login protection, or an app with real accounts — when any of these is true:

• "Who opened this" has to have an answer. Audit obligations, regulated data, anything where access is itself a record.
• Access has to be revocable per person. One contractor leaves; everyone else keeps working.
• The audience is a population, not a list. All employees, all customers, everyone who signs up next quarter. A link is addressed to people you chose; an account system governs a set that changes without you.
• The material is regulated. Health records, financial data under a compliance regime, anything where a policy document already tells you what the control must be.

For those, a private link is the wrong shape, and the extra login friction is the point rather than a cost. Say so early — it is much cheaper than discovering it after the fact.

Where the link is the right size of tool

And then there is the enormous middle, which is where most delivery work actually lives: a proposal for one client, a prototype for three reviewers, a report for the person who commissioned it, a build a colleague needs to click through before Friday.

For those, the honest accounting runs the other way. An account wall means your recipient signs up for a service to look at a thing you made for them — friction you are charging to the person you are trying to impress, in exchange for an audit trail nobody will read.

The layers that cover the realistic risks here are smaller than a login and do most of the work:

That last row is the one worth sitting with. The failure people actually experience is almost never a cracked URL; it is a recipient who was allowed in and then did something you did not expect. A login does not fix that either.

A shorter way to decide

One question does most of the sorting:

Does "which specific person opened this" need an answer?

• Yes → identity gate. Stop reading blog posts about links.
• No → a private link is the right size, and the remaining decisions are about which layers the contents warrant: password for anything with numbers in it, expiry for anything time-boxed, and a check that it is not indexable if it was never meant to be found.

The AI warning is a reasonable default for a machine answering a stranger with no idea what they are sending — of course it points at the stronger control. It just answers a different question from the one most people are asking, which is not "what is the most secure option" but "what is the right amount of control for this specific thing I need to hand someone this afternoon".

If you want the mechanics underneath the password layer — including the difference between a password that is a real gate and one that is a prompt drawn over content the browser already downloaded — how password protection actually works covers it. And if you are weighing a memorable address against an unguessable one, those two goals genuinely conflict, which is its own trade-off worth understanding before you pick.