Push notifications feel like a small feature, but they involve two security details worth getting right: the device token that identifies where to send, and the payload that travels to the device and may show on the lock screen. The common mistakes are putting sensitive data in the notification payload, where it passes through Apple's servers and can appear on a locked screen, and embedding your APNs credentials in the app, where they do not belong. Here is how device tokens and payloads work on iOS and how to handle both securely.
Short answer
On iOS, push notifications go through Apple Push Notification service (APNs). The device token identifies a specific app installation to APNs and should be treated as an identifier your server stores and validates, while your APNs authentication key or certificate must stay on your server, never in the app. Per Apple's documentation, do not put sensitive data in the notification payload, since it passes through APNs and can be displayed on the lock screen; instead send a minimal payload and have the app fetch sensitive details from your server, optionally using a notification service extension to fetch or decrypt content. Keep credentials server-side and keep sensitive data out of the payload.
What you should know
- APNs delivers iOS push: the device token routes to a specific installation.
- The token is an identifier: store and validate it server-side.
- APNs credentials stay server-side: the auth key or certificate is not for the app.
- Do not put sensitive data in the payload: it passes through APNs and the lock screen.
- Fetch sensitive details after open: send a minimal payload, then load from your server.
How do device tokens work, and how should you handle them?
The device token is APNs's address for a particular app on a particular device, and your server uses it to send. The system gives your app a device token, which you send to your backend, and your backend presents it to APNs along with your authentication to deliver a notification. The token is not exactly a secret like a password, but it identifies an installation and can change, so treat it as an identifier you store securely, associate with the right user, validate, and refresh when it rotates, rather than something to log or expose. What truly must stay protected is your APNs authentication, the auth key or certificate that lets you send on your behalf; that belongs only on your server, never embedded in the app, because anything in the app can be extracted, and an exposed APNs key would let someone send notifications as you.
What should you not put in the payload?
Anything sensitive, because the payload is not private. The table shows the concern.
| Payload content | Risk |
|---|---|
| Sensitive personal data | Visible on the lock screen and passes through APNs |
| Tokens or credentials | Exposed in transit and on the device |
| Full message contents | May display before authentication |
| A minimal identifier or hint | Acceptable; details fetched securely afterward |
The notification payload travels through APNs, so Apple's infrastructure handles it, and it can be displayed on the lock screen before the user authenticates, so treating it as a private channel is a mistake. A push payload should carry the minimum needed to prompt the user and let the app know what to load, not the sensitive content itself.
How do you send sensitive notifications safely?
Send a minimal payload, then fetch the sensitive details over your secure channel. The pattern is to include in the notification only what is necessary to alert the user and tell the app what to retrieve, an identifier or a generic hint, and then have the app fetch the actual sensitive content from your backend over HTTPS once the user opens the notification, where your normal authentication and access control apply. If you need to enrich or decrypt content before display, a notification service extension can fetch or decrypt it on the device, keeping the sensitive part out of the payload that crosses APNs. Keep your APNs authentication on your server, store device tokens securely and tied to the right user, and design the user-facing text so a lock-screen preview does not reveal something private. The principle is that the payload is a prompt, and the sensitive data lives behind your authenticated API.
What to watch out for
The first trap is putting sensitive data in the notification payload, which passes through APNs and can show on the lock screen; send a minimal payload and fetch details securely. The second is embedding your APNs auth key or certificate in the app, where it can be extracted; keep it server-side. The third is treating the device token carelessly, logging or exposing it, rather than handling it as an identifier tied to a user. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces hardcoded secrets and how the app handles data, so you can confirm no APNs credential is embedded and sensitive data is not mishandled. The payload and token design you implement in the app and backend.
What to take away
- iOS push goes through APNs; the device token is an identifier your server stores and validates, and your APNs auth key or certificate must stay server-side, never in the app.
- Do not put sensitive data in the notification payload, since it passes through APNs and can display on the lock screen.
- Send a minimal payload to prompt the user, then fetch sensitive details from your backend over HTTPS, using a notification service extension to enrich or decrypt if needed.
- Keep APNs credentials off the device, handle tokens as user-tied identifiers, and use a pre-submission scan such as PTKD.com to confirm no credential is embedded.
