How to Configure and Audit WebHID and WebSerial Device Access in Google Chrome

Modern web applications frequently interface directly with external hardware devices such as microcontroller boards, barcode scanners, flight simulator controllers, custom programmable keyboards, and medical diagnostic instruments. Google Chrome enables these hardware interactions through the WebHID (Human Interface Device) and WebSerial APIs. While these application programming interfaces facilitate responsive in-browser hardware management without requiring custom desktop client drivers, granting direct hardware communication privileges introduces distinct endpoint security risks. Malicious or compromised web domains can exploit unfiltered hardware access to exfiltrate microcontroller memory registers, alter device firmware, or inject unauthorised keystroke sequences. Understanding how to audit, restrict, and systematically revoke WebHID and WebSerial device permissions ensures enterprise endpoint compliance and protects personal workstations from physical peripheral attacks.

Understanding WebHID and WebSerial Architectural Interfaces

The WebHID API provides web applications with bidirectional communication mechanisms targeting USB and Bluetooth Human Interface Devices. Unlike standard operating system keyboard and mouse drivers—which intercept input at the kernel abstraction layer—WebHID communicates with auxiliary collections, feature reports, and vendor-defined interface endpoints. For instance, a web-based configuration utility for an mechanical split keyboard utilises WebHID to transmit layout configurations directly to the onboard microcontroller.

Conversely, the WebSerial API exposes serial communication ports—including physical RS-232 COM ports and virtual USB-to-UART bridge chips such as the CP2102, FTDI FT232R, and CH340. This allows development environments to program embedded hardware directly from a browser tab. Because serial interfaces do not enforce operating-system-level privilege boundaries once an open communication stream is established, any web application possessing active WebSerial authorisation can execute arbitrary binary read and write operations across connected peripheral buses.

Configuring Global Hardware Connection Prompts in Chrome Settings

Google Chrome enforces an explicit user-consent workflow before granting any web origin access to connected hardware. When a web application invokes either navigator.hid.requestDevice() or navigator.serial.requestPort(), Chrome renders a modal dialog enumerating the detected hardware devices. However, administrators and security-conscious users can adjust the browser’s global policy to block hardware permission requests entirely.

1. Launch Google Chrome, click the three-dot Customise and control Google Chrome menu icon in the upper-right corner, and select Settings.
2. In the left-hand navigation pane, select Privacy and security, then click Site settings.
3. Scroll down to the Permissions section and click Additional permissions to reveal extended hardware controls.
4. To control Human Interface Devices, click HID devices. Under Default behaviour, select Don’t allow sites to connect to any devices if you wish to block connection prompts universally.
5. Return to the Additional permissions menu and click Serial ports. Select Don’t allow sites to connect to any devices to restrict serial bridge discovery globally.

When set to block connection prompts, web applications attempting to initiate hardware handshakes receive an immediate user-rejection exception, mitigating clickjacking or social engineering vectors.

Auditing and Revoking Active Peripheral Permissions Per Origin

If you have previously granted peripheral access to development platforms, hardware diagnostic utilities, or firmware flashing tools, Chrome retains these authorizations across sessions. Regularly reviewing and revoking these persistent permissions is critical for maintaining tight endpoint hygiene.

1. Open Chrome and navigate directly to chrome://settings/content/hidDevices in the Omnibox.
2. Inspect the Allowed to connect to these devices section. Here, Chrome displays a structured tree of web origins paired with the specific hardware vendor ID (VID) and product ID (PID) granted access.
3. Click the trash can icon beside any origin-device pair to immediately terminate the persistent permission mapping.
4. Next, navigate to chrome://settings/content/serialPorts to review connected serial interfaces, COM ports, and USB-UART bridges.
5. Click the trash can icon next to any obsolete or untrusted development domain to revoke serial access.

Alternatively, permissions can be managed directly on an active webpage. Click the View site information icon (tune/sliders symbol) located on the left edge of the address bar, locate HID devices or Serial ports, and reset the permission state to default.

Monitoring Live WebHID and WebSerial Traffic via Chrome Internal Consoles

For systems administrators, developers, and forensic analysts, Google Chrome provides dedicated internal diagnostic interfaces to inspect real-time peripheral states, active event listeners, and hardware disconnection telemetry.

1. Open a new browser tab and type chrome://device-log into the Omnibox.
2. Under the Log level filter, select Debug and check the boxes for HID and Serial.
3. Click Refresh. Chrome produces a chronological audit trail documenting peripheral enumeration events, USB enumeration failures, endpoint connection handshakes, and input report parsing transactions.
4. To monitor active USB peripheral mappings, navigate to chrome://usb-internals to verify connected device descriptors, device configurations, and interface classes.

This internal logging capability enables enterprise security teams to verify whether an unauthorised web session attempted to open a raw telemetry stream to a local workstation peripheral.

Enforcing WebHID and WebSerial Restrictions via Enterprise Group Policy

Organisations deploying Google Chrome across managed enterprise fleets can enforce deterministic hardware connection policies using Chrome Enterprise Administrative Templates or Google Admin Console policies.

• DefaultWebHidGuardSetting: Setting this integer policy to 2 blocks the WebHID API entirely across all managed workstation profiles, preventing the browser from prompting users for peripheral access.
• WebHidAskForUrls: Accepts an array of approved origin URL patterns (such as https://flasher.firmware-vendor.internal) allowed to prompt users for device pairing while keeping global restrictions active.
• WebHidBlockedForUrls: Enforces an absolute blocklist of domains restricted from requesting HID device communication.
• DefaultWebSerialGuardSetting: Configured with value 2 to completely prohibit WebSerial communication prompts workstation-wide.
• SerialAllowAllPortsForUrls: Defines a trusted administrative list of origins permitted to establish serial connections to any enumerated hardware port without manual user confirmation dialogs.

Applying these enterprise policies through Group Policy Objects (GPO) in Active Directory or configuration profiles on managed operating systems prevents lateral peripheral access across high-security financial and corporate networks.