Quick summary: extension native messaging in 30 seconds
- Native messaging lets a Chrome extension exchange messages with a companion app installed on your OS—via chrome.runtime.connectNative / sendNativeMessage and a registered host manifest.
- That is a deliberate bridge past the browser sandbox: the native binary decides what files, devices, or daemons it can touch; the extension becomes a remote UI for those powers.
- Supply-chain risk is doubled—you must trust both the Web Store package and the desktop installer, which may update on different cadences.
- Legitimate uses include password managers, security tools, and hardware wallets from known vendors; random “helper” downloads paired with tiny extensions are a classic malware pattern.
Real-world lens: 1Password-style suites vs mystery helpers
Established security vendors document the native component, ship signed installers, and match extension ID to host allowlists. Bundles that arrive from ads or unofficial mirrors skip those assurances.
Native messaging is often paired with download APIs (drop or update binaries) or extension management (reinstall companions). Treat those triples as critical-risk until an IT owner vouches for them.
What native messaging enables (connectNative & host apps)
- Call connectNative or sendNativeMessage to start sessions with a host named in the extension manifest, subject to OS registration rules and allowed_origins in the native host JSON.
- Stream structured requests and responses for crypto operations, file picks, VPN control, or AV hooks—anything the vendor implemented in the companion binary.
- Chain with other extension powers: a native bridge plus downloads, management APIs, or broad site access can install helpers, exfiltrate data, or persist across browser profiles.
Abuse scenarios: trojan installers, host tampering & persistence
- Drive-by installers that push unknown “companion apps” alongside low-review extensions—users approve the browser piece but miss the binary’s capabilities.
- Independent update channels for the host binary: a clean Web Store listing while the desktop component turns malicious or is swapped in a supply-chain incident.
- Lateral movement: malware uses the extension as a UI to trigger file encryption, credential harvesting, or screenshot tooling implemented in native code.
Official docs: Chrome native messaging, runtime API & trust boundaries
Chrome native messaging lifecycle & runtime hooks
Google’s native-messaging guide covers host manifests, allowed_origins, message framing, and error cases—read it end-to-end before approving any paired download.Sources: Chrome — Native messaging · Chrome — runtime.connectNative
Permission warnings and declare-permissions explain how the capability surfaces at install; align those strings with every native component you deploy.Sources: Chrome — Declare permissions · Chrome — Permission warnings
Firefox parity & secure IPC culture
Mozilla documents the same bridge model for Firefox extensions—different registry keys, identical trust questions about the desktop binary.Sources: MDN — Native messaging
Secure development practices treat inter-process channels as security boundaries; CWE-923 captures risks when endpoints are not what developers intended.Sources: Microsoft — Secure Development Lifecycle · CWE-923
Practical tips: signatures, uninstall hygiene & enterprise allowlists
- Install host bundles only from the same vendor channel as the extension—official site or managed deployment—not third-party mirrors.
- Verify code signatures, auto-update sources, and uninstall dormant hosts when you remove the extension.
- On enterprise devices, allowlist extension IDs and native host paths; block unknown pairing installers.
- On personal devices, refuse bundles that add native messaging alongside extension-management or download APIs unless both components trace to the same trusted vendor channel.
Last reviewed: March 2026. Educational overview only—not legal advice; verify host registration steps against current Chrome documentation.
FAQ: Chrome native messaging & connectNative
Short answers for common searches—use with the risk and mitigation sections above for full context.
Further reading: native messaging docs & related eSafe guides
Map every Chrome extension permission bundled with a native bridge—especially downloads and extension management. For methodology, see analyze browser extensions.
- Chrome — Native messaging (concept)
- Chrome — runtime API (connectNative)
- Chrome — Declare permissions
- Chrome — Permission warnings
- MDN — Native messaging (Firefox)
- Microsoft — Secure Development Lifecycle (IPC trust)
- CWE-923 — Improper restriction of communication channel to intended endpoint
- eSafe — Full list of Chrome extension permissions
- eSafe — Downloads permission risks
- eSafe — Extension management (install/remove other add-ons)
- eSafe — Analyze browser extensions
Related extension guides
These topics often show up together in real extensions and abuse reporting—reading them as a set makes it easier to judge combined risk.
- Browser extensions & downloads (full guide)
What the downloads permission allows, silent droppers and metadata profiling, cited campaign scale, and mitigations.
- Chrome Extension Management Permission: Install/Remove Add-ons & Critical Risk
Chrome extension management permission: chrome.management can install/remove add-ons—supply-chain risk, when IT is legit, consumer red flags | eSafe
Audit what is installed
Pair least-privilege installs with a periodic review—especially after any extension update.