Is ADB in the Browser (WebUSB) Safe? Security and Privacy Explained

Yes, ADB in the browser over WebUSB is safe to use, provided you trust the site you open and treat USB debugging with the same care as any desktop ADB tool. A web page cannot see your phone until you pick it in the browser's device chooser, and cannot run ADB commands until you tap Allow on the phone itself. Those two independent approvals, plus the fact that the page only works while the tab is open, make the attack surface smaller than most people expect. This article explains each layer, shows where data goes in ADBKit, and lists the habits that keep you safe.

How WebUSB permission works

WebUSB is deliberately narrow:

• HTTPS only. The page you talk to is authenticated and cannot be altered in transit.
• User gesture required. A page cannot open the device chooser on its own. You must click something first.
• Picker, not enumeration. The page never gets a list of your USB devices. You select one device in the browser's chooser, and only that device becomes visible to the page.
• Per-origin. The permission belongs to one site. Granting adbkit.com access to your phone does not give any other site access.
• Revocable. In Chrome or Edge, click the lock icon in the address bar, open the site settings, and remove the USB device, or clear site data to wipe everything the site stored.

A page that never received a grant cannot even tell whether a phone is plugged in. More background is in what WebADB is.

How ADB authorization works

The browser grant only lets the page send bytes to the phone's ADB interface. Android then applies its own check, the same one desktop adb passes:

1. The page generates an RSA key pair the first time it connects. The private key is stored in the browser for that origin and never leaves your computer.
2. The phone receives the public key and shows the Allow USB debugging? prompt with the key's fingerprint.
3. If you tap Allow, the session opens. If you tick Always allow from this computer, the phone remembers that key and skips the prompt next time.
4. You can wipe the list with Revoke USB debugging authorizations in Developer options, or turn USB debugging off entirely.

Because the key lives in the browser, clearing site data removes it and the phone asks again. Another browser profile or computer has a different key and needs its own Allow. If the prompt never appears, see fixing ADB device busy or unauthorized.

What a web page can and cannot do

Once both approvals are in place, the page has the same power as the adb command: install packages, read logs, transfer files, control the screen. That is exactly why the approvals matter. The limits matter just as much:

There is no background access: a closed tab is a dead connection. And only one program can claim the ADB interface at a time, so a tab and a desktop adb server cannot both drive the phone.

What data flows where in ADBKit

ADBKit is built so that device data has only one path: between the browser tab and the phone.

• Screen frames, screenshots, recordings, logs, files, APKs and serial numbers go browser ↔ device only. ADBKit has no server that receives them.
• No account. There is no sign-in and no profile.
• Ads only on website pages. Home, blog and legal pages load Google AdSense; the workspace at /app does not, and ads never use device content.
• Analytics is opt-in. If you accept the notice, Google Analytics 4 counts page views and which feature was used, such as "opened Logcat". It never receives screen frames, files, logs, serial numbers, device model, package names or anything you type. Decline and the workspace works the same.
• Standard server logs. The host keeps request logs (IP address, user agent, URL) for security, with no device data.

What gets pushed to the phone

To mirror and control the screen, ADBKit copies the open-source scrcpy server component to a temporary location on the device and starts it over ADB. It is served from ADBKit's own origin, not a third party. No app is installed and nothing appears in your app list. Installing an APK is always your deliberate action in the Install APK panel, and ADBKit asks before replacing an existing app.

Note: Anything a browser does over ADB, a desktop tool could also do. The question is never "browser or desktop" but "do I trust this code with USB debugging".

Threat model and sensible practices

The realistic risks are the same ones that apply to desktop ADB, and the same habits defuse them.

• Trust the site before you click Allow. Only open WebADB pages you know. A phone prompt you did not expect is a reason to tap Deny.
• Keep USB debugging off when you do not need it. Turn it on for a session and off afterwards, especially on a phone with personal data. How to enable USB debugging shows where the switch lives.
• Do not leave "Always allow" on shared computers. On a lab PC or a colleague's laptop, tap Allow without the checkbox so the authorization dies with the session. If you did tick it, revoke authorizations afterwards.
• Be careful with ADB over Wi-Fi on public networks. adb tcpip 5555 makes the phone listen on the network. The RSA check still applies, but the traffic is not encrypted and an already-authorized machine on the same network could connect. Use it on a trusted network and run adb usb when done; see ADB over Wi-Fi. ADBKit's helper listens on 127.0.0.1 only, so other machines cannot reach it.
• Lock the screen and the computer. Anyone at your unlocked browser can use an open connection. Lock the workstation when you step away and disconnect when finished.

Warning: Revoking the browser's USB permission does not revoke the phone's authorization, and vice versa. If you want a clean slate, do both: remove the site permission in the browser and tap Revoke USB debugging authorizations on the phone.

Compared with desktop mirroring tools and cloud services

Installing a random desktop mirroring tool means running native code with full access to your computer, often with its own adb binary, driver and auto-updater. A web page runs inside the browser sandbox with only the one USB device you granted; on that axis the browser is the more constrained option.

Cloud mirroring and remote-device services send screen frames, and sometimes files, through their servers by design. That can be fine for a team feature, but if a service shows you the phone from another network, your data has left your machine. ADBKit's "browser" is local: the tab and the phone are on the same desk, joined by a cable.

How to audit it yourself

None of this needs to be taken on faith:

1. Check the foundations. ADBKit runs the open-source Tango (ya-webadb) ADB client and the scrcpy server. Both are public projects you can read.
2. Watch the network. Open DevTools, select the Network tab, connect your phone and use the live screen, logcat and file panel. You will see the page's own assets and, if you allowed it, small analytics events, but no frames, logs or files being uploaded, because there is no endpoint for them.
3. Inspect the permissions. The lock icon in the address bar shows which USB device the site holds; Developer options on the phone shows the authorizations you granted.
4. Revoke and reconnect. Remove the permission, clear site data, and confirm the phone prompts again: the key lived nowhere but your browser.

Used this way, ADB in the browser is as safe as ADB on the desktop, with fewer moving parts to keep patched. The rules are the same: trust the code, approve only the computers you mean to, and turn USB debugging off when done.