WebUSB Security Model and Exploit Prevention

The WebUSB API enables web applications to communicate directly with Universal Serial Bus (USB) devices from the browser. Because granting low-level hardware access to websites presents significant security risks, the WebUSB API is governed by a strict, multi-layered security model. This article explains the architectural safeguards and access controls designed to prevent malicious JavaScript from compromising connected hardware, accessing unauthorized devices, or attacking the underlying host operating system.

Secure Context Requirement

The WebUSB API is exclusively available within secure contexts (HTTPS). This ensures that communication between the browser and the web server is encrypted and authenticated. By preventing man-in-the-middle (MITM) attacks and unauthorized script injection, secure contexts guarantee that only trusted JavaScript served from the verified origin can attempt to interface with connected USB devices.

Explicit User Consent and Transient Activation

Malicious JavaScript cannot silently detect, scan, or connect to USB devices in the background. Accessing a device requires two distinct authorization steps:

1. Transient User Activation: The initial request function, navigator.usb.requestDevice(), can only be triggered by direct user interaction, such as clicking a button or pressing a key. Programmatic background invocation without user intent is blocked by the browser.
2. Native Device Chooser: When triggered, the browser presents a native, untrusted-origin-proof UI prompt (the device picker) displaying connected devices matching the site’s vendor and product ID filters. The user must manually select the device and confirm access. The website cannot influence the selection or bypass this dialog.

Protected Classes and Interface Blocking

To prevent severe exploits—such as injecting keystrokes (BadUSB attacks) or accessing sensitive credentials—the WebUSB specification explicitly blocks web pages from claiming certain standard USB interface classes. Browsers block WebUSB access to:

• Human Interface Devices (HID): Keyboards, mice, and game controllers.
• Mass Storage: Flash drives and external hard drives.
• Smart Cards and Security Tokens: Standard authentication hardware.
• Audio and Video Streams: Webcams and microphones (which must use dedicated media APIs with their own permission models).
• Wireless Controllers: Bluetooth and Wi-Fi adapters.

If a USB device exposes an interface belonging to a blocked class, the operating system driver or the browser engine rejects the claim, preventing malicious scripts from interacting with sensitive hardware peripherals.

Origin Isolation and Permissions Policy

WebUSB enforces the Same-Origin Policy. Permissions granted to one website (e.g., https://example.com) are not transferable or accessible to other origins.

Furthermore, access can be strictly managed through the HTTP Permissions-Policy header. Site owners can explicitly restrict or allow USB access using the usb directive:

• Embedded third-party <iframe> elements are blocked from accessing WebUSB by default.
• An iframe can only request access if the parent document explicitly grants it using the allow="usb" attribute.
• Domains can entirely disable the API across their applications by setting Permissions-Policy: usb=().

Device-Side Origin Restrictions (WebUSB Descriptors)

Hardware manufacturers can implement WebUSB Platform Capability Descriptors directly inside the device firmware. These descriptors allow a device to declare specific authorized origins allowed to communicate with it. When a site attempts to request the device, the browser reads these descriptors; if the requesting origin does not match the URL specified in the device firmware, the browser denies the connection request, mitigating the risk of malicious third-party websites connecting to custom hardware.