A deadline is not a guest list. An image link that closes tomorrow may still admit the wrong person today. For a small team sharing visual drafts, the useful question is not simply whether a link is “private,” but what a viewer must demonstrate before the image is released.

ChatPic’s public homepage advertises private share links, expiration, view limits and optional password protection. Its FAQ also notes that some options depend on configuration. These are product descriptions, not evidence of an independent security assessment. Understanding what each control is meant to do helps teams decide whether temporary sharing is enough or whether their workflow needs a separate access check.

Five controls, five different questions

An unlisted link: does the visitor have the address?

An unlisted image is not deliberately placed in a public gallery. Where possession of the link is the only access requirement, however, the address acts like a transferable key. A recipient can forward it, paste it into a group conversation or expose it in a screenshot.

A long, unpredictable link can make guessing harder. It does not establish who received it legitimately. Nor does “unlisted” automatically mean undiscoverable or excluded from search. For a low-risk draft, this may be an acceptable trade-off; for a named-client review, possession of the address may be the wrong admission rule.

Link expiration: is access still within the allowed time?

Expiration limits the period during which a service should honor a link. It can reduce the chance that an old message keeps providing access months after a project ends. It does not identify the person opening the link before that deadline.

It also cannot retract an image already saved or photographed. Link expiration, deletion from the hosting service and removal from backups are separate matters. A view limit similarly counts permitted openings; it does not establish that each opening belongs to an approved person.

A shared password: does the visitor know the secret?

A password adds a requirement beyond knowing the address. A strong, share-specific password sent separately from the link can reduce the consequences of forwarding the link alone. Sending both together makes them easy to forward together, too.

Everyone who knows a shared password presents the same evidence. It does not distinguish the client from a colleague who received it secondhand. Removing one reviewer may require changing the password for everyone. It can suit a small, low-risk review group, but it is not individual identity verification.

Account authentication: can the visitor authenticate to an approved account?

An account can support ongoing client access, individual permissions and revocation. Authentication checks the account’s credentials, which might involve a password or passkey. The account still needs permission to open the particular draft.

OWASP’s Authorization Cheat Sheet distinguishes authentication from authorization: successfully signing in does not entitle someone to every resource. A reviewer should receive access to the relevant project, not every client folder. An account name alone is not proof of legal identity, either; that depends on how the account was established and any separate identity-proofing process.

An SMS code: can the visitor access the intended number now?

A successfully checked one-time code is evidence of access to messages sent to that number at that moment. It is not proof of the recipient’s legal identity, their authority to represent a company, or their agreement to keep the image confidential. Codes can also be forwarded.

The number must already be associated with the intended reviewer. Asking anyone who finds a link to enter any phone number, then accepting a code sent there, verifies a contact channel—not entitlement to the draft.

NIST SP 800-63B-4 treats authentication over the public telephone network as restricted and states that out-of-band authentication is not phishing-resistant. SIM-swap fraud and number changes are among the risks it identifies. An SMS check may add a barrier to casual link forwarding, but it should not be presented as a high-assurance identity check. Two screens also do not automatically make a workflow multifactor authentication.

A hypothetical review for a Saudi client

Imagine a small Saudi design studio sharing an unreleased packaging mockup with one client contact. The draft contains no customer records or identity documents. The studio’s concern is accidental forwarding before the client has reviewed the design, rather than protection of highly sensitive material against a determined attacker.

The studio does not already have a client portal. It agrees with the contact to use a short phone-code check and associates the invitation with the Saudi mobile number established through their existing business relationship. This is a proposed developer-built workflow, not a description of ChatPic’s current implementation.

Opening the invitation would show a review-access page, not the image or a revealing thumbnail. The reviewer would request a code for the approved number. The application would keep the verification request tied to that invitation and browser session, rather than letting the visitor substitute another number or an unrelated verification result.

For this code-delivery step, Tawked is a potential component: its current Verify documentation describes server-side API operations to start and check an SMS code, with destinations limited to Saudi mobile numbers. The review application would still need separate protected image storage, permission checks and session management. This example does not describe an existing ChatPic integration, and the code result would not certify the client’s identity.

Only after the server confirms a successful result for the matching, still-active invitation would it create a limited review session for that draft. A message being accepted for delivery is not successful verification. The studio could close the invitation after the review or revoke it when the recipient changes.

Protect the image, not just the page in front of it

An access screen is ineffective if the underlying image remains available through a separate unrestricted address. Adding an OTP page that merely reveals a reusable image link does not make the image itself recipient-bound.

OWASP’s authorization guidance calls for permission checks on every request, including static resources. Applied to this workflow, that means covering originals, previews and download routes—not just the review page. Storage and caching arrangements must not provide an unprotected route around the check. These are requirements to evaluate in the chosen architecture, not claims about ChatPic’s implementation.

After access is granted, a reviewer can still take a screenshot or photograph the display. Removing a download button does not change that. Access controls can limit who receives an image through the application; they cannot guarantee what a permitted recipient does with it afterward.

Design the code’s whole lifecycle

Keep three clocks separate

The invitation’s lifetime, the code’s validity and the review session’s duration answer different questions. A link might remain available for the agreed review period while each code is valid only briefly. Completing verification should not create an indefinitely valid session.

NIST’s out-of-band authentication guidance requires completion within ten minutes and one-time acceptance of the secret. Treat that as an upper bound in that guidance, not a reason to choose the longest available setting. Enforce expiry on the server; an on-screen countdown is only an explanation. An old verification result must not become permission to open a different invitation.

If the studio promises that review access ends at the invitation deadline, session and image-access checks must enforce that deadline too. Shortening the code’s lifetime alone does not shorten an already-authorized session or erase an image already displayed.

Make resends predictable

Decide what “resend” means before writing the interface. If it issues a replacement code, invalidate the previous one and explain that only the latest code works. A retry after a network timeout should not accidentally create several independent challenges. Coordinate this behavior with the delivery component rather than assuming every provider handles it identically.

Provide a visible wait before another send is allowed, and enforce it on the server. Avoid sending a message automatically on every page refresh. Delayed messages should lead to a clear next step, not an invitation to request codes repeatedly.

Limit guesses and sends separately

A short numeric code needs server-enforced attempt limits. NIST specifically says that generating a new secret must not reset the failed-attempt count. The application should also prevent someone from evading its policy simply by starting fresh challenges.

Limit message requests as well as code guesses: repeated sends can annoy the client and consume the sender’s balance. Consider the recipient, invitation and overall application when setting limits. Use temporary cooldowns and a recovery path rather than making an outsider’s repeated failures a permanent lockout for the client.

Explain errors without exposing client information

OWASP’s Authentication Cheat Sheet recommends generic failure responses where extra detail would disclose whether an account exists. In a review flow, do not reveal whether arbitrary phone numbers belong to clients or display full contact details before verification.

The interface can still be helpful: “We could not verify that code. Check the latest message or request another when available.” For a cooldown, state when another attempt is possible. For a closed invitation, explain that access is no longer available and direct the reviewer to the sender. Do not label every failure a delivery problem.

Plan recovery before a client loses their number

A replacement-number field must not become a shortcut around the approved-recipient rule. For this studio, recovery could involve an authorized client contact using a previously agreed alternative route to reapprove the recipient, followed by a fresh invitation. Support staff should not simply disable the check because someone knows the project name.

If there is no adequately verified alternative, pause the review. A delivery outage or an unavailable phone should not silently turn a protected invitation into an open link.

Sometimes the right decision is not to collect a number

A phone check creates another interaction and another piece of personal data to manage. Before adding it, identify the specific failure it is meant to prevent. If a draft is already public, or contains only generic layout options that the team is comfortable circulating, collecting a phone number may add friction without meaningful benefit.

An existing client account with suitable authentication and project permissions may also make a new phone check redundant. For especially sensitive material, a purpose-built client portal with phishing-resistant authentication and explicit permissions is a better direction than assuming an SMS gate is sufficient. OWASP’s multifactor-authentication guidance cautions against SMS for high-value and personal-information-handling applications.

Where phone verification is justified, explain its purpose before requesting or using the number. Keep numbers and codes out of share URLs, limit staff access, and avoid retaining full codes in logs. Separate any ongoing customer contact record from temporary review-verification data, and set retention periods for each. Do not silently reuse a review-verification number for marketing.

Choose an admission rule you can explain

Before sending a draft, complete this sentence: “This image is available to…” The answer might be anyone holding the active link, anyone who also knows a shared password, an approved account, or someone who completes a code check for the approved Saudi number. Those are different promises.

Choose the rule that fits the image and the relationship, enforce it wherever the image is served, and state what it cannot do. A link’s expiry controls when access should stop. Authentication supplies evidence about an account or contact channel. Authorization decides whether that evidence is enough for this image. None of them, alone, guarantees confidentiality.