Compliance checklists (like NDPR or ISO 27001) are administrative baselines; they do not stop attackers from manipulating JSON payloads to steal money. Securing a payroll platform requires an adversarial mindset. You must assume the attacker already possesses legitimate credentials (e.g., a rogue HR admin or a compromised employee account) and audit the systemic boundaries preventing that insider from escalating privileges or manipulating the disbursement flow.
1. Defeating Maker/Checker (4-Eyes) Bulk Disbursement Logic
Enterprise payroll relies on the Maker/Checker principle: the HR Manager (Maker) uploads the bulk salary file, and the CFO (Checker) reviews and approves the disbursement. We aggressively attack the state machine between these two actions.
We upload a legitimate batch of 1,000 employees. The Maker submits it for approval. While the batch sits in the "Pending Approval" state, we intercept the API and issue a hidden `PATCH /api/batches/123/records/45` request, silently altering one employee's destination account number to our attacker-controlled account. If the backend does not enforce strict state immutability, the modification succeeds. When the CFO finally clicks "Approve," they unknowingly authorize the tampered batch.
The Remediation: The backend must cryptographically hash the batch payload the moment the Maker submits it. When the Checker approves, the backend must re-hash the current batch and compare it. If the hashes differ, the approval must hard-fail. Furthermore, any attempt to modify a batch in the "Pending Approval" state must instantly revert the batch to "Draft."
2. BOLA across Employee Salary Records
Multi-tenant payroll platforms frequently suffer from Broken Object Level Authorization (BOLA). The API retrieves employee records using sequential integers or UUIDs (e.g., `GET /api/companies/99/employees/4051`).
We authenticate as an HR admin for Company A. We intercept our own API traffic and systematically swap our `company_id` for Company B's ID, or iterate through employee IDs outside our organization. If the database query relies solely on the ID provided by the client rather than enforcing a strict tenant isolation constraint (`WHERE TenantId = @ContextTenantId`), we successfully exfiltrate the entire salary structure and PII of a competing firm.
3. Earned Wage Access (EWA) Race Conditions
Earned Wage Access (EWA) APIs are incredibly susceptible to concurrency attacks (Race Conditions). An employee is authorized to withdraw a maximum of ₦20,000 before payday. We utilize specialized tooling (like Turbo Intruder) to send 50 simultaneous withdrawal requests for ₦20,000 within a 10-millisecond window.
If the backend checks the balance, approves the withdrawal, and updates the database sequentially without enforcing strict row-level database locks (e.g., `SELECT FOR UPDATE` in PostgreSQL), multiple threads will read the initial balance simultaneously and approve multiple transactions. The attacker successfully withdraws ₦100,000 against a ₦20,000 limit, leaving the fintech to absorb the bad debt.
4. Bank Account Change Workflows and Account Takeover (ATO)
Attackers target the self-service portal where employees update their salary bank accounts. If an attacker phishes an employee, their first action is to alter the destination account right before payday.
We audit the account change workflow for critical security controls. Does the system mandate a fresh Multi-Factor Authentication (MFA) challenge specifically for the `PUT /api/employee/bank` endpoint? Does it implement a mandatory cooling-off period (e.g., 48 hours) before the new account becomes active for disbursements? Does the platform execute a Name Enquiry (BVN validation) to guarantee the new bank account name matches the employee's verified legal name? If these controls are missing, the platform facilitates frictionless wage theft.
5. Payslip Document Access and URL Predictability
Payslips are highly confidential documents containing tax identification numbers and net pay. Platforms often generate payslips as PDFs stored in AWS S3 buckets. If the platform generates predictable URLs (e.g., `s3.amazonaws.com/payslips/company_12/emp_405_july.pdf`) and fails to enforce signed URLs with strict expiration limits, attackers will script a scraper to download thousands of private financial records.
We ensure all sensitive documents are served via short-lived, cryptographically signed URLs or proxied strictly through authenticated backend controllers.
EWA inflation via unvalidated external employer API response
During a penetration test of a Nigerian EWA startup, we examined how the platform verified the user's monthly salary. The frontend app queried the employer's HR system, received the salary figure, and passed that figure directly to the EWA backend to calculate the withdrawal limit. We intercepted the traffic between the frontend and backend, changing the "salary" integer from 250,000 to 5,000,000. The backend blindly trusted the client-supplied parameter, instantly authorizing a massive, fraudulent withdrawal limit.
Operating a payroll or EWA platform in Nigeria? You process the highest-risk data in fintech. Schedule an adversarial security review today.
Book a Payroll Platform PentestFrequently asked questions
What makes payroll fintech a high-value target for attackers?
Payroll platforms aggregate identity, employment history, tax IDs, exact salary figures, and raw bank account details in a centralized database. Attackers leverage this data for mass account takeovers, highly targeted spear-phishing against executives, and direct financial theft by manipulating batch disbursement files.
How do attackers manipulate payroll run disbursements?
Attackers exploit Maker/Checker logic flaws. If the Maker submits a batch of 100 salaries for approval, the attacker intercepts the API request immediately after the Maker submits, modifying a beneficiary account number. If the backend fails to cryptographically lock the batch data before the Checker approves it, the altered batch executes.
What is Earned Wage Access (EWA) fraud?
EWA platforms allow employees to withdraw a portion of their earned salary before payday. Fraud occurs when attackers exploit race conditions to withdraw the same ₦50,000 limit multiple times concurrently, or manipulate the employer-verified salary API response to artificially inflate their approved withdrawal limit.
Tax Identifier Manipulation for Synthetic Identity Fraud
Nigerian payroll platforms must process Tax Identification Numbers (TIN) and National Identity Numbers (NIN) for statutory deductions. Attackers exploit these fields to commit synthetic identity fraud. If the payroll API allows a user to register multiple synthetic employees under a single valid NIN or BVN, the attacker can aggregate micro-salaries or systematically evade tax bracket thresholds.
We execute logic tests against the `POST /api/employees/onboard` endpoint. We attempt to bind the same BVN to twenty different synthetic employee records across three different companies. If the backend fails to enforce global uniqueness constraints on biometric identifiers, the platform is actively facilitating large-scale money laundering and tax evasion.
Related reading
Blog: BOLA in financial APIs · Name enquiry binding exploits · Insider threats in Nigerian fintechs
Services: Penetration testing · API security