A Go-To-URI action is a PDF action that opens a uniform resource identifier when the action is triggered. It can launch a web link or other URI handler from within the document, so PDF viewers often restrict or warn on it to reduce unwanted external navigation.
What a Go-To-URI Action Does
A Go-To-URI action is a PDF action that opens a URI when triggered, letting a document launch a web page, mail client, file handler, or other registered scheme handler. It is a convenience feature, but it also creates an external navigation path that may leave the document environment and hand control to the operating system or browser.
Why PDF Viewers Treat It Carefully
PDF viewers often treat URI-triggered actions as potentially risky because they can be used to send readers to unexpected destinations or to initiate actions outside the PDF sandbox. The security concern is not the URI itself, but the fact that a document can cause the user’s environment to make a trust decision on its behalf.
That makes the control boundary important: once a viewer permits the action, the resulting request is governed by browser, mail, or OS handling rather than by the PDF layer. This is why many readers warn first, disable the feature by policy, or require explicit user confirmation.
Common Uses and the Trust Boundary
Legitimate uses include “open a help page”, “jump to a support portal”, or “start an email draft” from within a form, manual, or report. In those cases, the action is serving document usability, not document security. The trust issue appears when the document is untrusted, the target is opaque, or the action is used to hide where the user will actually be sent.
Because URI handlers can vary by platform and application, the same action may behave differently across readers, browsers, and operating systems. That variability is one reason security teams prefer to test how PDF actions are handled in the exact deployment stack rather than assuming a uniform result.
Operational Implications for Document Security
Go-To-URI actions matter most in environments that process external PDFs at scale, such as customer support, procurement, finance, and legal workflows. In those settings, the main operational question is whether the organisation wants documents to be able to steer users into external destinations at all, or only in tightly controlled cases.
Security teams usually care about provenance, user expectation, and policy consistency. A harmless-looking PDF can still direct a user to a credential-harvesting page, a malicious download, or a tracking endpoint, so document inspection, content sanitisation, and reader hardening become part of the broader control strategy.
Risk and Threat Considerations
Go-To-URI actions can create phishing, malware-delivery, and unwanted-tracking risk because a document can trigger an external request without the user manually typing the destination. The danger is greatest when the link target is shortened, hidden behind benign text, or mixed with social engineering that encourages the user to trust the document.
Failure mechanism: The PDF action executes a URI handler that moves the user out of the PDF trust boundary, where the destination may collect credentials, launch a harmful payload, or fingerprint the endpoint.
Impact: Users can be redirected to malicious or deceptive content, exposed to download or credential theft attempts, or lured into actions that defeat the organisation’s document-review assumptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-18 — Mobile Code | Covers active content that can change system behavior when a document triggers external handling. |
| Recommendation — Restrict or disable document-triggered external actions where they can bypass your approved execution boundary. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | Addresses user-facing controls that reduce malicious navigation and unsafe web interactions from documents. |
| Recommendation — Harden user-facing applications to warn on or block unexpected external links from untrusted content. | ||
| NIST CSF 2.0 | PR.PS-03 — Information System Functionality is Protected | Applies because PDF-triggered URI handling is a user-facing function that should be bounded and protected. |
| Recommendation — Constrain document actions so external navigation occurs only under approved and monitored conditions. | ||
Practitioner Guidance
What to watch for: Treat Go-To-URI actions as a policy decision, not a formatting detail. If your environment receives untrusted PDFs, configure viewers to warn, restrict, or disable URI-triggered actions unless the workflow genuinely depends on them.
Governance implication: Decide which document classes may use external navigation, then align that rule with secure viewer configuration, user awareness, and file-handling controls. For high-trust internal documents, allow only explicit, reviewable destinations; for external or unknown documents, prefer blocking or sandboxing the action.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org