Yes, treat it as a secret. Under the Web Push protocol, authorization relies on capability URLs that act as bearer tokens, so anyone holding a push endpoint can send messages to that subscription. Store endpoints like credentials, keep them out of logs, and delete them when users unsubscribe.
Definition
Web Push, defined in RFC 8030, lets your server send messages to a browser through a push service. The protocol uses two URLs per subscription. The push resource is what your application server posts to. The spec calls it public in the sense that the user agent shares it with the application server, but it must not be disclosed to unauthorized parties. The subscription resource, used by the browser to receive messages and delete the subscription, is private to the browser.
The RFC asks for at least 120 bits of random entropy in the push URL path, which is why the URL is hard to guess, and why leaking it is the real risk.
What a leak allows
With only a push endpoint, an outsider could attempt to post messages to that subscription. Modern services add a layer: a subscription can be bound to your public key, so only a server with the matching private key can use it. RFC 8292 describes this as reducing reliance on keeping the URL secret, but it depends on that binding being in place, so do not rely on it without checking. See what VAPID is.
Handling rules
| Where it appears | Rule |
|---|---|
| Database | Treat as a credential; restrict access and consider encrypting at rest |
| Application logs | Do not log full endpoints; log a short hash or the subscription id |
| Error reports | Scrub endpoint URLs before sending to third parties |
| Analytics events | Never attach the endpoint |
| Support exports | Exclude it from data pulled for tickets |
| Backups | Same protection as the database |
Steps
- Search your logging and tracing configuration for push endpoints.
- Store the endpoint with the auth and key material the browser gave you, in a table with tight access.
- Delete a subscription on user opt-out and when the push service reports it is gone.
- Bind subscriptions to your VAPID key at subscribe time.
- Rotate sending keys on a plan, following the gradual migration advice in RFC 8292.
- Add the endpoint pattern to your redaction rules so a future log line cannot leak it.
URL secrecy also does not hide message content from the push service. The RFC says applications need end-to-end encryption for that, which is the job of message encryption. See what web push encryption does.
Where Safeguard fits
Safeguard's SBOM and dependency scanning helps you track the push libraries your server uses and check them against advisories. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Is the endpoint safe to log for debugging?
Avoid it. Log an identifier or a hash instead, because the endpoint works like a bearer token.
Does the push service read my messages?
Only if you send plaintext. Message encryption in RFC 8291 protects the content from the push service.
Sources
Last reviewed: 19 October 2026.
