Secure Photo Sharing: Expiring Links and Access Control

Start with the threat model: who are you keeping out?

"Secure" means nothing until you name the person you are securing against. For client photo work there are really only four, and they need different defences.

• The stranger who guesses. Someone who types or scripts URLs hoping to land on a gallery.
• The forwarded link. The client shares it with a colleague, who shares it with an agency, who pastes it in a group chat. Nobody is malicious; the audience just grows.
• The stale link. A gallery from a finished job that is still open long after anyone needs it.
• The crawler. A search engine or link-preview bot that finds the page. We cover that one in whether client review links get indexed by Google.

For most shoots the forwarded link and the stale link are the realistic problems. Guessing is a mathematical non-issue if the link is built properly, as the next section shows. Where a shoot is sensitive (an unreleased product, a celebrity portrait, a minor's photos) the threat model changes and the controls you pick should too.

Why a long random link already beats most passwords

A link is a bearer credential: whoever holds it can open the gallery. That is fine as long as the token inside it cannot be guessed. The arithmetic is simple enough to do yourself.

A 4-digit code can be exhausted by a script in moments. A six-character slug looks sturdier, but a few billion possibilities is within reach of automated guessing if the server does not rate-limit. A 128-bit random token is a different category: even a million guesses per second would not make a dent in 2¹²⁸ possibilities in any timescale that matters.

The practical rule: judge a gallery host by how its links are made. If the address is a sequential ID, a gallery name, or your client's surname (/smith-wedding), it is guessable by design. If it carries a long random token, guessing is off the table and your attention should move to the forwarded and stale cases.

Expiring links: the control for stale galleries

An expiry date shrinks the window in which any leaked or forwarded link is useful. It is the cheapest control there is, because it asks nothing of the client. They click, they review, and the link quietly stops working when the job is over.

Here is the exposure arithmetic. Suppose you shoot 12 jobs a year and leave every gallery open for five years. That is 12 × 5 = 60 live links at any moment, each one a way in that nobody is watching. With a 30-day expiry you have about one live link at a time. Cutting from 30 days to 7 shrinks each link's window by a factor of 30 ÷ 7 ≈ 4.3.

Expiry is a trade-off, not a free win. A client who returns in month three to find the gallery gone will email you, and you will spend time re-issuing it. Choose the window by the job: a proofing round with a deadline can expire close to the deadline, while a wedding gallery the couple will revisit needs a much longer one. How long to keep client galleries online works through the storage-cost side of the same decision.

Two details matter. First, the link should be re-issuable or extendable without changing the photos. Second, you want a separate revoke action: expiry handles time, but revocation handles "the client just told me the wrong person has this."

Passwords and PINs: useful, but know what they cost

A password on a gallery protects against the forwarded link, because the recipient needs the second secret too. It also adds friction for exactly the person you most want to make things easy for, your client, and it shifts a support task onto you: "what was the password again?"

The table is a judgement, not a measurement, but it shows the pattern: no single control covers all four rows. A password is worth its friction when the content is sensitive or the client list is long. For a family session sent to one parent, it mostly generates emails.

If you do use one, send it through a different channel than the link. A link and a password in the same email give you no more protection than the link alone, because anyone who can read that email has both.

Access logs: the control that tells you what happened

Logs do not prevent anything. They answer questions after the fact, and that is worth more than it sounds. When a client says "I never saw the second batch," a record of when the gallery was opened settles it in seconds. When a leak does happen, a log shows whether it was opened from places you did not expect.

The useful questions a log should answer are narrow: was this gallery opened, when, and how often? You do not need to know more about your clients than that, and collecting more is a privacy liability of its own. Record the minimum, keep it only as long as the job needs it, and say so if a client asks.

Five sharing mistakes that undo good controls

Controls only work if the habits around them do. These are the failures that show up most often when a gallery link causes trouble, and none needs special software to fix.

1. Pasting the link into a public place. A link posted in a social bio, a public comment thread or a shared channel with outside guests is public, whatever the gallery settings say. Send it directly to the person it is for.
2. One link for every client. If forty people share a single link, you cannot revoke it for one without cutting off the other thirty-nine. Issue one link per person or per group, so revoking is surgical.
3. Putting the password in the same message. Send the link by email and the password by text, or the reverse. Two channels is the whole point of a second secret.
4. Never checking the link signed out. Open it in a private window before you send it. If you see a login wall you did not intend, or more than the client should see, you want to find out before they do.
5. Forgetting the original files. A locked proof gallery protects nothing if the full-resolution files also sit in a shared folder with a public link. Secure the delivery path, not just the proofing page.

A worked example shows how the pieces combine. You shoot a product launch for a client under embargo. You send one link to the brand manager, set to expire seven days after the round deadline, with a password sent by text. When the manager says they want to loop in the agency, you issue the agency its own link instead of letting the first one be forwarded. When the round closes, you revoke both. At no point did anyone outside the named people have a working way in, and you can show who was given access.

Compare that with the default approach: a shared cloud folder set to "anyone with the link," emailed to a manager who forwards it to six people. Nothing about it is malicious, and nothing about it is controlled either. The difference is not software; it is deciding in advance who gets a link, for how long, and how you would end it.

Matching controls to the shoot

Put it together by shoot type. This is a starting point; adjust for your contracts.

The same thinking applies when you hand files to someone else on the team. Scope access to one job and make it end, rather than inviting a freelancer into a shared folder that stays open for years; freelance retoucher handoff without a shared Dropbox covers that case.

Appruva review links are built on this model: a link grants access to the shared object only, can be given an expiry, and can be revoked at any time so it stops opening for everyone. Whatever tool you use, check those three behaviours before you send the first link.