WebUSB, WebHID and Web Serial need an origin-level device policy, dev.to post argues

Hardware access has moved into the web origin

Browsers can now hand USB, human interface and serial devices directly to web applications, and a post on dev.to argues that the shift demands a device policy defined at the origin level. The three APIs cover distinct territory: WebUSB exposes services on compatible USB devices, WebHID targets uncommon or exotic human interface devices, and Web Serial connects to serial ports, including hardware that appears as a USB or Bluetooth serial adapter.

The convenience is real, since hardware workflows no longer need a native installer. But the post warns that a device permission decision now lives inside the web origin, where a compromised script, a third-party iframe or an overly broad feature policy can change who gets access.

The device chooser is mediation, not trust

According to the post, MDN documents these 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, but it does not make every script on the origin trustworthy. Once a site is permitted to request devices, any script executing in the same origin may be able to initiate the request, and a malicious dependency can present a plausible interface of its own and ask the user to pick a device.

Device descriptors add context but are not a policy. A vendor ID, product ID, serial number or interface class identifies a device family; it does not prove the firmware is current, that the device belongs to the right user, or that the requested operation is safe for the hardware.

Permissions-Policy is the first gate

The post points to the Permissions-Policy directives usb, hid and serial, which control whether a document can use each API. The default allowlist is limited, but a parent document can delegate access to a cross-origin frame, a delegation the post describes as a security decision in itself.

The recommendations are concrete. Send a deny-by-default header such as Permissions-Policy: usb=(), hid=(), serial=() on pages that do not need device access. When an application does need a capability, scope the policy to the trusted origin and load the feature on a dedicated page instead of enabling it across a marketing site or a broad administrative domain, because 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, since a policy that looks correct at the top level can still delegate access through an allow attribute on a child frame, and inventory both the header and the frame attributes.

Design device access as a capability

Applications should identify the exact device class and operation they need rather than requesting every device the chooser can list: a firmware updater needs a different workflow from a temperature sensor reader, and a keyboard configuration tool may need a specific HID usage page and report format.

Where the browser supports filters, the chooser should be filtered, with vendor and product names shown before access is granted. The page should explain what it will read and write, and whether the operation can change persistent device state. After the operation, the interface should be released and the device closed so another application can use it.

Serial devices warrant extra care. The post treats the serial path and baud configuration as part of the request, because a page that can write arbitrary bytes to a management console or a microcontroller bootloader holds more authority than one that only reads a sensor value. It recommends separating read-only and write-capable roles where the hardware allows.

Logging and failure behavior

Logs should record the origin, the permission decision, the device class, the operation, the result and the user context, while avoiding full device serial numbers when a stable internal asset ID will do. Disconnects and permission revocation should be handled as normal states: the application should fail closed and explain the state rather than automatically retrying a privileged write.

What the policy does not solve

The post is explicit about limits. These APIs are not a general endpoint security boundary: native drivers can still be vulnerable, malicious devices can still send unexpected data, and a browser extension with stronger host permissions may see more than the page does. The web permission governs only the browser-mediated path. Its defensive value is narrower — it restricts which origins can reach specific hardware at all.

Why it matters

As hardware access becomes a web capability, the security boundary moves from installers and operating systems to the origin and everything that executes inside it, including third-party dependencies and embedded frames. A permissive default turns one compromised script into a potential path to firmware updaters, bootloaders and management consoles. The remedy the post proposes is cheap and standards-based: deny the 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 a device workflow as visible and auditable as a sensitive network endpoint or a file permission, which is where browser-based hardware access needs to sit.