Navigator.sendBeacon

How Navigator.sendBeacon Works

Navigator.sendBeacon lets a browser queue a small outbound request without waiting for a page to stay open. Because the transfer is asynchronous and best-effort, it is designed for telemetry, logging, and analytics events that should not interrupt navigation.

The key design choice is that the browser, not the script, owns the timing and delivery attempt. That makes the method suitable for "fire and forget" reporting, but it also means the application cannot depend on a response body, a status-driven workflow, or immediate confirmation that the server accepted the data.

Where It Fits in Browser Networking

sendBeacon sits in the narrow space between full fetch-style request handling and pure client-side state capture. It is commonly used during unload, pagehide, or similar lifecycle moments when ordinary asynchronous requests may be cancelled or delayed by the browser.

That placement matters because unload-time network activity is constrained by browser behavior, user privacy protections, and the need to preserve page responsiveness. Developers often choose it when they need a low-friction way to preserve last-moment signals, such as session end markers, interaction summaries, or abandon events.

Its utility is therefore operational, not transactional. If the data must be acknowledged, retried, correlated with a live response, or used to drive a user-facing decision, another request pattern is usually a better fit.

Delivery Semantics and Limitations

The method is intentionally unreliable in the strict systems sense: it makes a best-effort attempt rather than a guaranteed one. That means network failures, browser shutdown, offline state, storage pressure, or page lifecycle constraints can all prevent delivery without giving the calling code a recovery path.

Payloads are meant to be small, and the method is not a general transport for complex API interactions. It also does not support the same interaction model as a normal request, so it is a poor choice when the sender needs custom control over headers, retries, redirects, or response handling.

That limitation is not a flaw, it is the security and performance trade-off that makes the API safe to use at the edge of navigation. The browser can release the page without blocking, while the application accepts that some events may never arrive.

Security and Privacy Considerations

Because sendBeacon is often used for telemetry, it can carry sensitive behavioral data if teams are careless about event design. The main concern is not the API itself, but the data it is asked to emit, especially when it includes identifiers, session context, or other information that users may not expect to be persisted after navigation.

Teams should treat beaconed data as production telemetry, not harmless diagnostics. That means minimising payload content, validating server-side ingestion, and ensuring the endpoint only accepts the specific signals it is meant to receive. A browser beacon that is simple to send can still become an exfiltration or tracking path if the receiving service is overly permissive.

For general control alignment, the surrounding telemetry pipeline benefits from NIST SP 800-53 Rev 5 Security and Privacy Controls, while the browser-side risk of overexposed collection patterns is also well framed by the OWASP API Security Top 10.

Risk and Threat Considerations

sendBeacon is attractive in abuse scenarios because it can quietly move data at a moment when the user is leaving the page and the application is least able to intervene. If the endpoint accepts broad input or the page emits excessive context, the same convenience that helps analytics can also help covert tracking, data leakage, or noisy ingestion abuse.

Failure mechanism: The browser’s best-effort delivery model removes user-visible confirmation, while a weak receiving endpoint or overly rich payload design creates room for unintended disclosure or tampered telemetry.

Impact: Security teams may lose confidence in analytics integrity, privacy boundaries may be crossed, and sensitive interaction data may be exfiltrated or misused without a reliable client-side signal that anything went wrong.

Related resources from NHI Mgmt Group

• ATT&CK Navigator
• navigator.webdriver