Password-Protected Link

Why It Matters

Most files people publish are not secret, but some are merely not-for-everyone: a board pack, an unreleased price list, a client draft. A shareable link with no gate is readable by anyone who guesses, scrapes or is forwarded it, and search engines will index it if anything ever points at it. A password turns a public object into one that needs a deliberate hand-off. The failure most likely to undo it is human: send the password in the same email as the link and you have shared nothing but an extra click. Send it by a different channel and one leaked message is no longer enough.

How It Works

The host marks the file as gated and checks that flag at the edge, before it reads a single byte of the object. An unauthenticated request gets the prompt page — or, in the older HTTP Basic style, a 401 response with a WWW-Authenticate header that makes the browser pop its own dialog. A correct submission is verified against a hash of the password, never a stored copy of it, and the visitor receives a short-lived signed cookie so the rest of the session is not interrupted on every image and stylesheet. The gate only holds if the whole exchange runs over HTTPS; on a plain connection the password crosses the network in the clear. A wrong answer is rejected without saying whether the file exists, and repeated attempts are rate-limited so the password cannot be brute-forced.

Real-World Example

Common Mistakes

• ✕Sending the link and the password in the same message — one forwarded email then carries both halves and the gate has achieved nothing
• ✕Using a password that identifies the content, such as the client's name plus the year — it is the first thing anyone would try
• ✕Assuming the gate encrypts the file at rest — it controls who may request the object, not how the object is stored
• ✕Leaving the same password in place for months across several audiences, so there is no way to tell which hand-off leaked it

Related Terms