How push authentication works in Nigerian fintech apps
Push-based transaction authentication follows this flow: a user initiates a high-value transaction on their device or on a web interface, the backend creates a pending transaction record and sends a push notification to the user's registered device via Firebase Cloud Messaging (FCM) or Apple Push Notification Service (APNs), the user receives the notification, opens the app, reviews the transaction details, and approves or rejects. The approval message is sent from the app to the backend API, and the transaction executes or cancels accordingly.
The security of this flow depends on three controls: the cryptographic binding of the approval to the specific transaction (so the approval cannot be reused for a different transaction), the correct display of transaction details in the notification (so the user knows what they are approving), and the enforcement of the approval requirement at the backend (so the transaction cannot execute without a valid approval event, even if an attacker calls the execution endpoint directly).
1. MFA push fatigue attack simulation
We simulate a push fatigue attack by generating rapid consecutive push authentication requests for an attacker-controlled transaction. On the testing account, we send 20 to 30 approval requests in quick succession. We observe whether the platform rate-limits the approval request generation, whether it alerts the account holder to the unusual volume of approval requests through a secondary channel, and whether the platform automatically locks the account after a defined number of pending approvals within a short window.
For Nigerian users on unstable connectivity, a variation of this attack is particularly effective: send approval requests when the user's device is offline. The notifications stack up and deliver simultaneously when connectivity is restored. The user, seeing a rush of notifications, may approve one quickly to clear their notification shade without reading the transaction details carefully.
2. Approval bypass via direct execution endpoint call
The most critical test in push authentication: can the transaction execution endpoint be called directly without a valid push approval event? An attacker who has compromised a user's session token should not be able to execute a high-value transaction by calling the execution API directly — they should be blocked because no push approval has been received from the user's registered device. We test whether the execution endpoint independently verifies that a valid, unexpired, device-signed approval exists for the transaction before executing.
# Test: call transaction execution without push approval
curl -X POST https://api.fintech.ng/v1/transfers/execute \
-H "Authorization: Bearer compromised_session_token" \
-d '{"transfer_id": "txn_abc123"}'
# If this executes without requiring a push approval token: critical finding
# The push auth requirement must be enforced server-side, not just in the app UI3. Approval token replay and reuse testing
When a user approves a push authentication request, the app sends an approval token to the backend. This token should be: bound to the specific transaction ID it is approving, single-use (invalidated immediately after the first use), short-lived (expired after a time window matching the notification delivery window), and cryptographically signed by the device's push token or a device-bound key.
We test whether capturing an approval token for one transaction allows it to be replayed for a different transaction, whether the same approval token can be submitted twice to trigger double execution, and whether the approval token remains valid after the transaction it approves has been cancelled or expired.
4. Notification content information disclosure
Push notifications are visible on the device lock screen in most Android and iOS configurations. On a shared or unattended device, a push authentication notification that displays the full account number, full beneficiary name, or the full transaction amount is disclosing sensitive financial information to anyone who can see the device. We audit the content of push authentication notifications for minimum necessary disclosure: the notification should display enough for the user to identify the transaction (last four digits of the account, shortened beneficiary name, approximate amount), but not the complete financial details that appear in the full in-app approval screen.
5. Device registration and de-registration authorization
Push authentication is bound to a registered device. We test the device registration and de-registration flow: can an attacker register a new device for push authentication without re-authenticating, can an attacker de-register a victim's legitimate device before registering their own (creating a window where approval requests go to the attacker's device), and is device registration limited to one active device per account or can multiple devices be registered simultaneously?
Transaction execution endpoint did not verify push approval existence
During a penetration test of a Nigerian neobank that had implemented push-based transaction approval, we intercepted the transfer flow using Burp Suite. We identified the transaction execution endpoint and called it directly with a valid session token and a pending transfer ID — without ever approving the push notification on the registered device. The transfer executed successfully. The backend had implemented the push notification flow as a UI-only requirement: the notification was sent, but the execution endpoint did not validate that an approval had been received before processing the transfer. Fix priority: critical. The push approval was purely cosmetic. Any attacker with a valid session token could bypass it entirely. Remediated by adding a required approval_token field to the execution endpoint and validating its signature, binding to the transfer ID, and expiry before processing.
Implementing push-based transaction approval in your Nigerian fintech app? Book a security assessment that validates the server-side enforcement of your approval flow.
Book a Push Auth Security AuditFrequently asked questions
What is push notification MFA fatigue and why is it especially dangerous in Nigeria?
Push notification MFA fatigue involves bombarding a target user with rapid successive push authentication requests. A frustrated or confused user eventually approves one to make the notifications stop. In Nigeria, the risk is elevated by two factors: many users receive app notifications from multiple financial apps simultaneously, creating ambient notification noise that lowers attention per notification, and intermittent connectivity means users sometimes approve notifications they cannot fully read because the app will close or the notification will disappear if they do not act quickly.
Can an attacker spoof a push authentication notification?
Spoofing a push notification to look like it comes from a legitimate fintech app requires either access to the FCM or APNs push token registered by the device (which is held server-side), or control of the push notification delivery infrastructure. What attackers can do more practically is send a crafted push notification from a look-alike app installed on the device, which appears in the notification shade with a similar icon and message to the legitimate fintech app's authentication request.
What approval information must be shown in a push authentication notification?
At minimum, a push authentication request for a financial transaction must display: the transaction type, the amount, the destination account or beneficiary name, and the time of the request. A notification that says only 'Approve this transaction?' without the specific transaction details is a security failure — it creates conditions for silent approval of a fraudulent transaction by a user who did not read the details.
Related reading
Blog: SIM swap fraud defense testing · OTP fallback vulnerabilities · Insider threats and 2FA bypass
Services: Penetration testing · Authentication security