Join our Newsletter — 33% off our NHI Course
Home› Glossary› Threats, Abuse & Incident Response› URL Scheme Allowlisting
Threats, Abuse & Incident Response

URL Scheme Allowlisting

← Back to Glossary
By NHI Mgmt Group Updated October 31, 2026 Domain: Threats, Abuse & Incident Response

URL scheme allowlisting is the practice of permitting only specific schemes such as http and https while blocking dangerous alternatives like javascript:, file:, and smb:. For AI agent clients, it is a basic control that prevents remote metadata from becoming code execution or token theft.

What URL scheme allowlisting does

URL scheme allowlisting constrains which URL schemes an application or client will accept, usually permitting only web-safe schemes such as http and https. It is a defensive parsing control: the input is treated as untrusted until the scheme is checked, so dangerous handlers such as javascript:, file:, or smb: never reach a browser, OS handler, or embedded client.

The practical value of the control is that it narrows the set of things a link can do before any navigation, redirection, or external application handoff occurs. That matters because many exploitation paths begin with a seemingly ordinary URL that resolves to a different execution context than the user expected.

Why dangerous schemes are risky

Not all URL schemes behave like web navigation. Some invoke local file access, script execution, native handlers, or cross-application bridges, which turns a link into an action rather than just a locator. In browsers, mobile apps, and AI agent clients, that difference can be enough to convert remote content into code execution, local data access, or credential exposure.

Scheme abuse is especially dangerous when software assumes that any URL-shaped string is safe to open. A maliciously chosen scheme can redirect trust away from the intended website and into the platform’s own handlers, where the security boundary is weaker and the consequences are often outside the application’s normal controls.

For mobile and native environments, deep-link and redirect handling are particularly relevant. Mobile Deep Link and App Link Security Guide explains how custom scheme handling, claimed links, and redirect validation intersect with app-level trust decisions.

Where allowlisting is needed in real systems

Allowlisting should be applied anywhere a URL is accepted from remote content, user input, API responses, or model-generated output. That includes link previews, content renderers, browsers inside apps, OAuth redirect handling, notification taps, document viewers, and AI agent clients that may fetch, open, or follow links on behalf of a user.

In practice, the control is most effective when paired with scheme normalization and strict parser behavior. A weak implementation may compare raw strings instead of parsed schemes, mishandle case or encoding quirks, or allow an approved scheme to carry a dangerous payload in another part of the URL.

For native app login and redirect flows, scheme control is part of a broader trust boundary. OAuth for Native and Mobile Apps Guide covers why claimed HTTPS redirects and browser-based flows reduce the risk of custom scheme abuse.

When the client is a mobile app, scheme handling should be considered alongside platform trust decisions, link verification, and safe rendering. Swift and iOS Secure Coding Guide provides the iOS-specific context for safe trust handling and link-related security patterns.

How allowlisting supports safe navigation and execution boundaries

The security benefit is not just blocking a bad string. It is preserving the boundary between external content and privileged local actions. If the only permitted schemes are those that map to ordinary web retrieval, the client can display, route, and inspect links without accidentally invoking script handlers, local file access, or privileged inter-process behaviors.

This makes URL scheme allowlisting a low-friction control with high leverage. It reduces the chance that remote metadata, chat content, or user-supplied links become a path to session theft, token exposure, or unauthorized local access, especially where the application automatically prefetches, previews, or opens links.

For detection and broader control design, scheme allowlisting fits well with standard security control baselines. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful control-catalog reference for access control, integrity, logging, and configuration discipline around user-facing input handling.

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, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5AC-4 — Information Flow EnforcementRestricts how untrusted links and handlers can move data into privileged contexts.
SI-10 — Information Input ValidationURL schemes are untrusted input that must be validated before use.
Recommendation — Enforce scheme allowlisting at the input boundary before a URL can trigger navigation or handler invocation. Validate parsed URL schemes against an approved list and reject unexpected handlers.
OWASP ASVSV13 — ConfigurationClient-side trust decisions and protocol handling belong in secure configuration and platform controls.
Recommendation — Harden client configuration so only approved URL schemes can be opened or processed.
CIS Controls v8CIS-16 — Application Software SecuritySecure application behavior includes validating untrusted link handling paths.
Recommendation — Build scheme allowlisting into application security requirements and review link-handling code paths.

Practitioner Guidance

What to watch for: Treat URL schemes as an allowlist decision, not a string-formatting detail. The dangerous failure mode is accepting a link because it looks like a URL while ignoring the scheme-specific behavior that determines whether it opens a browser, invokes a local handler, or exposes sensitive local state.

Practitioner takeaway: The safest default is to parse the URL, validate the scheme against a narrow approved list, and reject anything that depends on platform-specific handler behavior to become safe.

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.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org