Web Bluetooth API Security and User Permissions

The Web Bluetooth API enables web applications to discover, connect to, and interact with nearby Bluetooth Low Energy (BLE) peripherals directly from the browser. Because granting web applications direct access to hardware poses significant privacy and safety risks, modern browsers enforce a stringent multi-layered security model. This article details the core security requirements and user permissions governing Web Bluetooth implementations, including secure contexts, explicit user gestures, native device pickers, GATT service filtering, and service blocklists.

Secure Contexts (HTTPS)

Web Bluetooth is strictly restricted to secure contexts. Browsers will only expose the navigator.bluetooth interface on pages served via HTTPS or from secure development origins such as localhost. This prevents man-in-the-middle (MITM) attacks where an adversary could inject malicious scripts to intercept or manipulate device communications, harvest sensor data, or tamper with connected hardware.

User Activation and Interaction

A web application cannot scan for or connect to Bluetooth devices automatically in the background. The request to connect to a device must be triggered by a direct, transient user interaction (a user gesture), such as a button click or tap event. Calling navigator.bluetooth.requestDevice() outside an explicit event handler results in a rejected promise and a security exception.

The Browser Device Chooser

When a site invokes navigator.bluetooth.requestDevice(), the browser displays a native, trusted system dialog that the webpage cannot style, bypass, or manipulate. This dialog displays the devices that match the filters defined by the application. The user must manually select a device and click "Pair" or "Connect" to grant access. A web application cannot automatically select a device or force a connection without this explicit affirmative user action.

Scoping Access via GATT Services

Security operates under the principle of least privilege. When requesting a device, developers must explicitly declare the Generic Attribute Profile (GATT) services the application intends to access using filters or the optionalServices parameter.

If an application connects to a device, the browser restricts API access only to the declared services and their associated characteristics. Any attempt to read, write, or subscribe to an undeclared service is blocked by the browser, preventing unauthorized access to sensitive sensors or administrative functions on the peripheral.

The GATT Blocklist

To prevent attacks such as keystroke injection or credential theft, web browsers maintain a hardcoded blocklist of universally known and sensitive GATT services, characteristics, and descriptors. Even if a user grants access to a device and the developer specifies the service in their application code, the browser will refuse access to:

• Human Interface Device (HID) services (to prevent keylogging or spoofing keyboard and mouse inputs)
• FIDO and Fast IDentity Online authenticators
• System-level device management and firmware update endpoints where misuse could brick the hardware

Permissions Policy in Iframes

By default, embedded <iframe> elements cannot access the Web Bluetooth API. If a parent document needs to delegate Bluetooth permissions to a third-party or embedded frame, it must explicitly grant permission using the Permissions-Policy HTTP header or the allow attribute on the iframe tag (e.g., allow="bluetooth"). This prevents embedded third-party widgets or advertisements from silently prompting the user for hardware access.

Permission Revocation and Persistence

Once granted, Bluetooth access is scoped to the specific device selected and the origin of the webpage. Users retain the ability to inspect and revoke device permissions at any time via the browser's site settings or origin information panel (often located near the address bar). Furthermore, closing the tab or navigating away terminates the active connection, ensuring that background tabs do not maintain continuous, untracked communication with nearby hardware without the user's ongoing awareness.