Mobile Push Notification Privacy Review
A push payload travels beyond an app view. Its alert can appear on a locked phone, watch, car display, notification history, mirrored device, backup, or provider console. Treat title, body, subtitle, action label, attachment URL, custom data, sound choice, and deep link as separate disclosure surfaces. Encryption in transit does not make displayed content private from somebody holding the device.
Apple UserNotifications supports alerts, sounds, badges, categories, actions, local notifications, and remote notifications delivered through APNs. Android notification channels let users control behavior per category. Product design must respect those controls: a channel name and notification category should not disclose sensitive context either.
Build a payload inventory
Inventory every template, including errors and test messages. Record data origin, recipients, rendering surfaces, lock-screen policy, and owner. Do not accept “only the ID is sent” without checking whether that ID appears in logs, URLs, analytics, or a deep link.
| Template | Minimal visible text | Payload rule | Owner | Pass criteria |
|---|---|---|---|---|
| New secure message | “You have a new message” | opaque message reference only | messaging owner | no sender, preview, or account name on lock screen |
| Payment event | “Action needed in app” | no amount, merchant, or OTP | payments owner | tap requires current session and opens verified record |
| Security warning | “Review your account security” | no device, location, IP, or recovery code | identity owner | app fetches detail after authentication |
Visible text should be useful without revealing a person, balance, diagnosis, message content, destination, or security secret. “Your code is 123456” and “Transfer of IDR 8,000,000 approved” fail before device testing starts. A notification also must not contain bearer tokens, passwords, session IDs, reset links, or an attachment URL that anyone can fetch.
Design lock-screen behavior deliberately
Platform settings belong to user, not app. App can request notification authorization and choose content, but cannot promise that every device will hide previews. Test with previews enabled and disabled, locked and unlocked, and on paired surfaces. Android uses channel importance and user settings; iOS exposes authorization and notification settings through UNUserNotificationCenter. Document expected behavior, then degrade safe when settings differ.
Use neutral copy as baseline. If business need requires detail, make detail an opt-in product setting with clear warning, approved owner, and retest after OS upgrade. Treat a user choice to show previews as permission to display that content on their device, not permission to add more data to payloads.
A notification service extension can modify an iOS payload before display, but it is not a place to trust unverified custom data or place credentials. A notification tap must route through normal app authorization. Resolve opaque reference after validating session, account access, resource state, and action freshness. Never make a deep-link parameter proof of access.
Concrete test procedure
- Capture provider request and app-received payload using synthetic data. Inspect every visible and custom field.
- Lock device; test banner, lock screen, history, grouped notification, wearable or mirrored display where supported. Screenshot evidence must contain synthetic data only.
- Deny notifications, disable previews, mute channel, revoke session, switch account, and tap an old notification. Confirm app does not reveal protected record or perform action.
- Test expired, altered, replayed, and cross-account opaque references. Server must reject each.
- Review provider dashboards, delivery logs, crash logs, and analytics for copied payload fields.
Pass when payload contains minimum opaque data, every protected detail is fetched after authorization, lock-screen rendering is neutral, user controls remain effective, and operational logs exclude sensitive content. Fail when account-specific content, OTP, financial data, health data, secret, or reusable URL appears outside authenticated app UI.
Exceptions, remediation, evidence
Owner: feature owner approves purpose; mobile owner implements presentation; backend owner validates references; privacy owner reviews data minimization. Evidence: template inventory, redacted test captures, channel/category configuration, build ID, server authorization tests, and exception record.
Exception needs concrete user need, disclosed visible fields, affected platforms, risk owner, expiry, and compensating controls. “Urgent” alone is not an exception. Remediate failures by replacing copy with neutral text, removing data from custom payload, using short-lived opaque references, requiring reauthentication, restricting logs, and rerunning locked-device tests. APNs and other providers attempt delivery but do not guarantee it; notification must never be only security-critical action path.
Mobile application penetration testing can validate rendered surfaces and authorization after notification interaction.
Worked case: locked-screen delivery
Create a test account with a neutral label and trigger a payment-status notification while device is locked. Expected output contains no recipient name, balance, OTP, account suffix, or action URL that grants access without reopening protected app state. Compare lock-screen text, notification history, wearable mirror, and screenshot-preview behavior. Revoke notification permission, rotate device token, then send same event. Delivery system should record an undeliverable or suppressed outcome without retrying stale token indefinitely. Closure evidence includes redacted provider event identifiers, device settings state, and screenshots with sensitive values absent.
Edge tests before closure
Test grouped notifications, copied text, deep links after session expiry, and notification opened by another device user profile. A deep link may identify an event but must re-establish authorization inside app. Retest after localization changes because translated templates often add operational detail. Close issue only after product owner accepts displayed data classification and release trace proves approved template version.