The broadcast-channel npm package is a healthy, actively maintained library for sending messages between browser tabs and Node.js processes, with no known direct vulnerabilities — but cross-tab messaging has security boundaries you need to understand before you put anything sensitive on the wire. This review covers what the package does beyond the native API, its maintenance and supply chain posture, the threat model of same-origin messaging, and when you should just use the platform primitive instead.
What the package does
broadcast-channel (GitHub: pubkey/broadcast-channel, from the maintainer of RxDB) implements a publish-subscribe channel between contexts that share an origin: browser tabs, iframes, workers, and even separate Node.js processes. The API mirrors the native BroadcastChannel:
import { BroadcastChannel } from "broadcast-channel";
const channel = new BroadcastChannel("session-events");
channel.onmessage = (msg) => {
if (msg.type === "logout") clearLocalSession();
};
// in another tab
channel.postMessage({ type: "logout" });
Its value over the platform API comes from two things. First, transport fallbacks: it picks the fastest available method per environment — native BroadcastChannel where present, IndexedDB or localStorage polling in older browsers and odd webviews, and a socket-based method in Node.js. Second, a LeaderElection module that lets exactly one tab claim a role (say, holding the single WebSocket connection or running background sync) and hands over leadership when that tab closes.
Health and maintenance status
By the boring metrics that actually predict dependency trouble, npm broadcast-channel scores well:
- Downloads: around 2.7 million per week, driven partly by prominent dependents (it has appeared in the dependency trees of popular auth and data libraries).
- Release cadence: the 7.x line has seen steady releases, and health trackers rate its maintenance as healthy with recent activity.
- Vulnerabilities: no direct CVEs recorded against the package in the public advisory databases.
- Bus factor: primarily one maintainer (pubkey), which is typical for utility packages of this size and worth noting rather than worrying about — the project has a long, consistent history.
The practical takeaway from a dependency health review standpoint: this is a low-risk package to adopt, and the main thing to monitor is the usual supply chain hygiene — lockfile pinning, provenance where available, and alerting on unusual publishes, the kind of monitoring an SCA platform such as Safeguard automates across your whole tree.
The security model: same-origin is the only wall
Everything about cross-tab messaging follows from one fact: the channel is scoped to the origin. Any JavaScript running on app.example.com can open the same named channel and both send and receive. That gives you two concrete rules.
Messages are not authenticated. A message on the channel tells you some script on your origin sent it — nothing more. If an attacker gets XSS on any page of the origin, they can inject forged messages into every open tab and read everything broadcast. Design message handlers so a forged message cannot escalate anything: treat { type: "logout" } broadcasts as a UX convenience (safe: worst case, the user re-authenticates), but never implement something like { type: "grant-admin" } where a spoofed message changes authority.
Do not broadcast secrets. Tokens, passwords, and PII do not belong on the channel, and with this library specifically there is an extra reason: in fallback mode, messages may transit localStorage, which means they can be written to disk and linger beyond the message's logical lifetime. Broadcast references and events ("session refreshed", "cart updated — refetch"), not the sensitive payloads themselves.
A third, subtler point: message handlers are input handlers. Validate the shape of what arrives (a type allowlist and schema check) exactly as you would validate a postMessage event, because on a compromised origin the sender is hostile, and even on a healthy origin a stale tab running last week's deploy may send shapes your new code does not expect.
The classic use case: logout and session sync
The most common production use is session synchronization — user logs out in one tab, all tabs drop their session:
const auth = new BroadcastChannel("auth");
export function broadcastLogout() {
auth.postMessage({ type: "logout", at: Date.now() });
}
auth.onmessage = (msg) => {
if (msg && msg.type === "logout") {
stopTokenRefresh();
window.location.assign("/login");
}
};
Note what this design gets right: the message triggers removal of local state and a redirect. Server-side session invalidation still happens through the API. If a tab misses the broadcast, its next API call fails auth anyway. The channel improves UX; it is not the enforcement mechanism.
Leader election, and why you might want it
LeaderElection solves the "n tabs, one job" problem without a server:
import { BroadcastChannel, createLeaderElection } from "broadcast-channel";
const channel = new BroadcastChannel("workers");
const elector = createLeaderElection(channel);
elector.awaitLeadership().then(() => {
// only one tab ever gets here at a time
openWebSocket();
});
This is genuinely hard to hand-roll correctly (tab crashes, laptop sleep, and race conditions on startup all bite), and it is the strongest reason to pick this package over the native API when you need the pattern.
Alternatives: when the native API is enough
The native BroadcastChannel API has been in every evergreen browser for years — Chrome and Firefox since much earlier, and Safari since 15.4 in 2022 — so if you only target modern browsers and do not need leader election or Node.js interop, the platform primitive with zero dependencies is the better default:
const channel = new window.BroadcastChannel("session-events");
Other adjacent options: localStorage storage events (the old-school fallback, fine for tiny flags), SharedWorker (heavier, but gives you a real shared execution context), and service-worker postMessage fan-out (useful if you already run one). Reach for the npm package when you need its fallbacks, its Node.js transport, or LeaderElection; otherwise every dependency you skip is one less entry in the next dependency audit.
Review verdict
Adopt without much hesitation, with standard controls: pin it in your lockfile, keep it current on the 7.x line, validate incoming message shapes, and keep secrets off the channel. The package's risk profile is dominated not by its own code but by the general rule of cross-tab messaging — the origin is the trust boundary, and XSS anywhere on the origin owns the channel. That makes your content security policy and output encoding part of this package's security story too.
FAQ
Is the broadcast-channel npm package still maintained?
Yes. The project (pubkey/broadcast-channel) shows a healthy release cadence on its 7.x line, active issue handling, and roughly 2.7 million weekly downloads. No direct vulnerabilities are recorded against it in public advisory databases.
Should I use broadcast-channel or the native BroadcastChannel API?
Use the native API if you only target modern browsers and just need simple pub-sub — it has been universally supported since Safari 15.4. Choose the npm package when you need legacy fallbacks, Node.js process messaging, or its built-in leader election.
Can other websites read my broadcast-channel messages?
No. Channels are same-origin scoped, so only scripts on your exact origin can join. The real risk is XSS on your own origin: any injected script can send and receive on your channels, so never let a broadcast message grant authority or carry secrets.
Is it safe to send auth tokens between tabs with broadcast-channel?
Avoid it. Broadcast events like "session refreshed" and let each tab read the token from its normal storage. In fallback transports, messages can pass through localStorage, giving secrets a longer, disk-backed lifetime than you intended.