OTP-protected links: how to share files and services without relying only on a URL

The problem: a forwarded URL does not identify the right recipient

Sharing a link is convenient, but a URL alone does not prove that the person opening it is the intended recipient. If the link is forwarded, pasted into the wrong chat or left stored in an old email, any future access will depend on how the resource is configured. OWASP warns that a visible reference in a URL or parameter should not be treated as sufficient authorization to access an object; the application must verify permissions before delivering the content.

In operations, training, support or agencies, the risk is not always a sophisticated attacker. The failure often comes from normal processes: sending a dossier to too many people, keeping a form open after the deadline, mixing internal collaboration with public links or not removing access when a project closes. That is why it is useful to design an access layer before publishing: decide the audience, permitted action, availability period and verification method.

What each layer controls in Apification

Apification Cloud lets you manage files, services and digital projects in an organized, versioned space designed for sharing. New resources are not public by default: they remain private until their visibility is changed or recipients are configured. This foundation is important because it avoids starting from an open link and forces a decision on how each item will be exposed.

The controls are not equivalent. In Apification, users, groups, links and publication are managed through independent controls. Access can be granted to specific users or reusable groups without publishing the item, while publication exposes a configured view or link without giving access to the account. OTP protects a public interaction, but it does not replace internal permissions; external authentication delegates identity checks to compatible providers when the service requires an existing account.

• User or group permissions: suitable for authenticated collaboration and controlled internal access.
• Shared link: useful for distribution, as long as its scope and actions are limited.
• OTP: adds a one-time verification step before allowing protected participation.
• External authentication: appropriate when an identity must be checked through a compatible provider.
• Restrictions and windows: limit start dates, expiration, capacity, participation rules and service conditions.

When to use OTP-protected links

OTP-protected links are a good fit when the recipient should not become a permanent collaborator, but it is still useful to verify the interaction before delivering a file, opening a form or allowing participation. For example, a delivery to registered attendees, support material for identified customers or a page published during a campaign can benefit from a one-time code sent through the configured channel.

They are also useful when the content does not justify creating internal access for each person, but an open link would be too broad. In Apification forms, public access can be replaced by OTP or supported external authentication, together with publication windows and response limits. This lets a team combine audience, verification, activity period and participation control without giving more access than necessary to the original resource.

• Use it for one-off access with identifiable external recipients.
• Use it for sensitive materials that should not remain indefinitely accessible through an open URL.
• Use it for published services, such as forms or registration pages, when participation must be protected.
• Use it when revoking future access is part of the operating process.

When OTP is not enough and what expectations to adjust

OTP controls access before the protected interaction, but it does not control everything that happens afterward. If the recipient downloads a document, takes screenshots, copies text or redistributes the file through another channel, link protection no longer prevents those later uses. This distinction is essential: the measures described control access in Apification; they do not turn the downloaded file into an object that is impossible to forward.

Nor should it be assumed that protecting the link encrypts, signs or stamps the downloaded PDF. Apification can deliver the stored original without altering the Cloud item and can also generate transformed downloads for delivery without replacing the source. If there are legal, contractual or confidentiality obligations, the owner must complement them with policies, communications, agreements and document management; Apification provides the available records, but retention, export and legal interpretation belong to the owner according to their obligations.

• Do not use OTP as a substitute for confidentiality agreements when the risk is later redistribution.
• Do not treat it as automatic legal proof of identity if your process requires specific external validations.
• Do not confuse control of access to the resource with permanent control of the file once downloaded.
• Do not publish highly sensitive content if you do not accept the residual risk of copying or screenshots.

Recommended flow in Apification

The safest path starts by choosing the audience before choosing the link. First prepare the file, form, page or service in Cloud and verify that the final content is in the right place. If it is an office document, it can be edited with ONLYOFFICE while keeping it inside Cloud storage; if it is an already transformed resource, remember that the transformed download is generated for delivery and does not replace the original.

Then decide who should access it and what they should be able to do: view, participate or download. Apification can show the recipient only the actions permitted by the resource. Configure users or groups if you need authenticated collaboration; use publication and a link if distribution is external; add OTP or external authentication if participation should not be open; and limit start dates, expiration, capacity, participation rules or service-specific conditions when applicable.

• Confirm that the new resource remains private until visibility or recipients are configured.
• Define the audience: user, group, public with link, OTP or external authentication.
• Reduce actions: only view, participate or download if the case requires it.
• Activate a publication window with a start date and expiration when access is temporary.
• Test as a recipient before sending the final link.

Practical example: training dossier for registered attendees

Imagine a training team that needs to deliver a dossier to registered attendees after an event. Publishing an open URL for months would be convenient, but not very controlled. In Apification, the team can keep the dossier in Cloud, preserve the original managed in the workspace and prepare a delivery that shows only the necessary actions, for example downloading the material or viewing it if that is the intended experience.

The flow would be operational: upload or prepare the dossier, confirm the registered audience, publish access for a defined period and require OTP before allowing protected participation. If the dossier is offered in a transformed format, that delivery does not replace the stored original. When the window ends, changing visibility, users or groups updates future access, while the owner retains control of the original and its history inside Cloud.

• Before sending: validate the correct file, the readable download name and the intended audience.
• During delivery: use OTP and a publication window aligned with the course period.
• After closing: remove or adjust visibility and document what access should have existed.

Testing matrix before publishing

Testing the link as the owner is not enough. The test should simulate real recipients and failure conditions. OWASP recognizes the ability to bypass controls by modifying the URL, the application state, the HTML page or API requests as a broken access control pattern. Even if the team is not performing a full technical audit, it can still verify that the resource is not delivered when authorization is missing or when the window is no longer active.

It is worth repeating these tests whenever visibility, audience, download or period changes. In Apification, changes to visibility, users or groups update future access, but that does not remove the need to check the external experience. Use a private browser, a mobile device and an account without permissions to avoid false conclusions caused by already signed-in sessions or browser caches.

• Authorized user: can access and sees only the permitted actions.
• Unauthorized user: should not obtain the content just by knowing the URL.
• Incorrect OTP: protected participation should not open.
• Expired link: the expired window should block new access.
• Private browser: confirm that you are not relying on an open internal session.
• Mobile: check that the OTP and download flow is understandable.
• Transformed download: verify the format and confirm that the Cloud original is not replaced.

Common mistakes and decision criteria

The most common mistake is sharing first and protecting later. If an open URL has already circulated, adding OTP later may reduce future access, but it does not recover downloaded copies or prevent earlier screenshots. Another frequent failure is mixing public links with internal permissions: granting authenticated collaboration to someone who only needed to download a file unnecessarily increases the scope. Apification separates internal collaboration, public visibility and file delivery precisely to avoid granting more access than necessary.

As a practical criterion, use user or group permissions when there is an ongoing collaboration relationship; use a link with restrictions when distribution is broad but low risk; add OTP when you want to verify one-time participation; rely on compatible external authentication when the service requires an existing account; and apply publication windows whenever access has a natural start and end date. Document who should access, for how long, through which channel access is communicated and who will review removal.

• Do not leave links open indefinitely for operational convenience.
• Do not assume that a protected link changes the security of the file outside Apification.
• Do not forget to test users without permissions and expired links.
• Do not confuse available records with automatic legal interpretation.
• Do not grant internal collaboration if you only need controlled delivery.

Frequently asked questions