Security

What is yours to protect, and how.

Keep the secret on the server

Your app secret signs publish requests and channel authorizations. Anyone who has it can publish to your app and authorize themselves onto any private channel.

• Read it from an environment variable or a secrets manager on your servers.
• Never put it in browser code, a mobile app, a public repository or a log line.
• If it leaks, rotate it from the app's Overview. The old secret stops working immediately, so update your servers first or immediately after. Shared demo links stop working too.

The key and app id are not secret: they identify your app and ship to every client.

Authorize every private subscription

A private or presence channel is only as private as your authorization endpoint. It should:

• require a signed-in user,
• check that this user may join this specific channel, not just that they are logged in,
• never sign a channel name that merely matches a pattern the client chose.

See Authentication.

Do not trust client events

Client events skip your server, so any member of the channel can send any data. Use them for lightweight, non-authoritative signals such as typing indicators, and publish anything that matters from your server. See Client events.

Use TLS

Connect over wss and call the HTTP API over https. In the Pusher libraries that is forceTLS: true in the browser and useTLS: true on the server.

Roles in your team

Each member of your organization has a role. Only owners and admins can invite people or delete apps. Developers can read and rotate secrets but cannot delete apps or see billing. Billing and Viewer roles never see an app's secret. Give people the least access they need.

Reporting a problem

If you find a security issue in the service, write to the support address on the site with the details. Please do not post it publicly first.