Can a Shared Link Expose More Than You Intended? A Public-Sharing Checklist for Self-Hosted Apps

Treat the link as a permission, not just a URL

A share link can grant access beyond the application’s usual sign-in boundary. Before sending one, establish what a recipient can see or do, and whether access depends on the URL alone or on another documented requirement.

Box warns that anyone who correctly guesses a public custom link can gain access to its content. That describes Box’s sharing context, not every self-hosted app; check the documentation and behavior of the application you operate. [Read Box’s guidance on securing shared links](https://docs.box.com/en/box-fundamentals/for-users/collaborating/using-shared-links/securing-shared-links).

Self-hosting alone does not establish that external sharing is private. The application’s controls, your configuration, and users’ choices all matter.

• Identify what the link authorizes: viewing, downloading, editing, commenting, or another action.
• Determine whether access is public, authenticated, password-protected, or limited in another documented way.
• Record the intended recipient and purpose before creating a link.

Map the link’s scope

A link to a file, record, folder, or page may expose only that object—or make related material reachable too. The exact behavior is application-specific. Check documentation and test whether attachments, comments, activity history, related records, embedded content, or parent and child items are accessible.

For a collection or folder, establish whether items added later become accessible through an existing link. Apply the narrowest scope that meets the sharing need. Esri warns that making all items available to everyone can increase the chance of inadvertently exposing sensitive or proprietary information. [Read Esri’s sharing best practices](https://enterprise.arcgis.com/en/portal/11.3/use/best-practices-share.htm).

• List the target item and related objects that could be visible from it.
• Test whether a recipient can navigate to adjacent records, parent folders, or other items.
• Check whether content added later becomes visible through the existing link.

Test who can open the link and what they can do

Verify whether a recipient must sign in, enter an additional credential, belong to a specific account or group, or simply possess the URL. Requirements vary by application and configuration; a sign-in screen—or its absence—does not by itself explain the full access model.

Test in a clean browser session that is not signed in. If the application offers an additional credential or recipient restriction, test that path too. A link may behave differently for someone who already has an account, session, or permission.

Inspect what the recipient sees before opening the main content, including previews, thumbnails, page titles, filenames, descriptions, and comments. Test available actions such as downloading, printing, copying, or exporting. Verify documented indexing behavior for your application rather than assuming a setting makes a link private.

• Try the link in a clean, signed-out browser session and through the intended recipient’s authentication path.
• Review previews and metadata for information you do not intend to share.
• Test the recipient’s available actions and verify relevant indexing behavior in the application’s documentation.

Verify expiration and revocation with the original link

Check whether the application documents an expiry control and how it works, including any timing rule. Do not assume that a control exists because another application offers it.

Test revocation using a link that has already been copied or sent: disable the share using the documented process, then open the original URL in a clean session. If it still works, investigate whether revocation was incomplete, another route exposes the content, or the behavior is documented.

Deleting the message or email that contained the link is not a revocation test. The question is whether the already-issued URL still grants access.

• Confirm whether expiry is supported and what behavior to expect when it takes effect.
• Revoke a test link, then revisit the original URL in a clean session.
• Check whether changing permissions, moving the content, or disabling a user affects existing links.

Check what administrators can review

Find out what evidence the application records when a link is created, changed, accessed, expired, or revoked. Logs and their level of detail vary by application and configuration; do not assume that every visitor or action is recorded.

Verify who can review the evidence, how it can be exported, and how long it is retained. Test that the events you would need to investigate actually appear in the available logs or other documented evidence. Record gaps that matter to your organization.

• Look for records of link creation, scope changes, access, and revocation.
• Verify what an event identifies, who can access the records, and how long evidence is retained.
• Document any gaps that could affect an investigation or compliance requirement.

Make the test repeatable and assign ownership

Use sample content with no sensitive information to reproduce the workflow an employee is likely to follow. Test the link’s scope, recipient access, available actions, expiry or revocation where supported, and the administrator evidence available for those events.

Record the application and configuration tested, the steps taken, expected results, and what actually happened. Repeat the test after changes to sharing settings or application configuration that could affect access.

Decide who may create external shares, who approves sensitive ones, and who is responsible for reviewing or ending access. Provide a tested fallback—such as a documented authenticated sharing path or another approved transfer process—when a public link’s protections are insufficient or unclear.

Airbip manages infrastructure for self-hosted application instances, including deployment as Docker workloads on its cloud servers, routing and TLS certificates, DNS checks, service lifecycle management, and configurable backups. Those infrastructure services do not establish which sharing controls a particular application offers or remove the need to set access and data-handling policies.

• Use representative sample content and a clean, signed-out recipient context.
• Record test steps, expected and actual results, and relevant configuration.
• Name the share owner and set a review or end date.
• Define who can create links, when approval is required, and how to report unexpected access.