WebUSB, WebHID, and Web Serial need an origin-level device policy

Browsers can now expose USB, human interface, and serial devices to web applications. These APIs make hardware workflows possible without a native installer. They also move a device permission decision into the web origin, where a compromised script, a third-party iframe, or an overly broad feature policy can change who gets access.

The browser mediates access

The WebUSB API exposes compatible USB device services to web content. The WebHID API covers uncommon or exotic human interface devices. The Web Serial API connects to serial ports, including devices that appear as USB or Bluetooth serial adapters. MDN marks the device APIs as available only in secure contexts, and the browser presents a device chooser before a page receives access.

That chooser is a deliberate user-mediation point. It does not make every script on the origin trustworthy. Once a site is allowed to request devices, any script that can execute in the same origin may be able to initiate the request. A malicious dependency can also present a plausible interface and ask the user to select a device.

The device descriptor adds context but should not replace policy. A vendor ID, product ID, serial number, or interface class identifies the device family. It does not prove that the firmware is current, that the device is assigned to the right user, or that the requested operation is safe for the device.

Permissions Policy is the first gate

The Permissions-Policy directives usb, hid, and serial control whether a document can use the corresponding API. The default allowlist is limited, but a parent document can delegate access to a cross-origin frame. That delegation is a security decision.

Use a deny-by-default header on pages that do not need device access. For example:

Permissions-Policy: usb=(), hid=(), serial=()

If one application needs a specific capability, scope the policy to the trusted origin and load the feature on a dedicated page. Avoid enabling device access across an entire marketing site or a broad administrative domain. An injected script on a page that already has the feature can use the same permission path as the intended application.

Test iframe behavior from the same parent that runs in production. A policy that looks correct on the top-level page can still delegate access through an allow attribute on a child frame. Inventory both the HTTP header and the frame attributes.

Design the device workflow as a capability

Ask the application to identify the exact device class and operation. A firmware updater needs a different workflow from a temperature sensor reader. A keyboard configuration tool may need a specific HID usage page and report format. Do not request access to every device merely because the API supports a broad chooser.

Filter the chooser where the browser supports filters. Show the vendor and product name before the user grants access. Explain what the page will read and write, and whether the operation can change persistent device state. After the operation, release the interface and close the device so another application can use it.

For serial devices, treat the serial path and baud configuration as part of the request. A page that can write arbitrary bytes to a management console or a microcontroller bootloader has more authority than a page that only reads a sensor value. Separate read-only and write-capable roles when the hardware supports it.

Log the right events

Record the origin, permission decision, device class, operation, result, and user context. Avoid logging a full device serial number when a stable internal asset ID will do. A support log should be able to answer which page requested the device and whether the browser granted access, without becoming a device inventory leak.

Handle disconnects and permission revocation as normal states. A device can disappear, a user can revoke access, or the operating system can reclaim the interface. The application should fail closed and explain the state rather than retrying a privileged write automatically.

Limits and defensive value

These APIs do not provide a general endpoint security boundary. A native driver can still be vulnerable. A malicious device can still send unexpected data. A browser extension with stronger host permissions may see more than the page. The web permission only controls the browser-mediated path.

The control is still useful because it narrows which origins can reach specific hardware. Deny device APIs by default, delegate them only on dedicated pages, filter the chooser, require a user action, and test cross-origin frames. That combination makes the device workflow visible in the same way a sensitive network endpoint or file permission should be visible.

References

• MDN, WebUSB API
• MDN, Web Serial API
• MDN, Permissions-Policy: usb
• MDN, Permissions-Policy: hid
• MDN, Permissions-Policy: serial