Clearing the Security Bar for NRS E-Invoicing Integration
An anonymized look at how Hackrowd assessed an NRS e-invoicing integration platform — the APIs, cloud estate, and admin tooling behind it — so the provider could complete certification as a System Integrator and Access Point Provider with evidence, not assumptions.
Client identity, systems, payloads, and screenshots are withheld. Findings below are generalised and anonymized; technical detail was shared only in the confidential report.
The Context
Nigeria's National Revenue Service e-invoicing programme requires that companies transmitting invoice data on behalf of taxpayers — System Integrators and Access Point Providers — can demonstrate that their platform protects taxpayer data end to end. That means an independent security assessment of the integration itself: the APIs that receive and forward invoices, the credentials and keys that authenticate them, the multi-tenant boundaries that keep one taxpayer's data away from another's, and the cloud estate underneath.
The client in this case study is one of several providers Hackrowd has assessed ahead of certification. Their identity, architecture diagrams, and report contents remain confidential.
The Challenge
The platform had been built quickly to meet the integration deadline. It worked — invoices flowed — but nobody had asked the adversarial questions: could one integrator read another's invoices? Could a forged callback mark a fraudulent invoice as accepted? Were signing keys recoverable from logs? The team needed those answers before a regulator or an enterprise customer asked them first, and they needed them documented in a form both a compliance reviewer and an engineer would accept.
Scope & Methodology
In scope
- Invoice submission, validation, and status-callback APIs
- Taxpayer onboarding and multi-tenant isolation boundaries
- Admin console, privileged roles, and authentication flows
- Secrets, signing keys, and credential lifecycle
- Cloud infrastructure, IAM, and container baselines
- External attack surface of the integration platform
How we tested
- Black-box reconnaissance, then grey-box testing with tenant-scoped accounts
- Manual, senior-led API abuse and authorization testing across tenants
- Invoice integrity, replay, and forged-callback attack simulation
- Business-logic testing of onboarding and submission workflows
- Configuration review of cloud, IAM, secrets, and containers
- Every finding manually validated, CVSS-scored, and CWE-mapped
Delivered by senior, OSCP-certified testers. No junior hand-offs, no scanner output passed off as findings.
Anonymized Findings
49 findings were reported. The issues below are described at a level that is useful to other integrators without identifying the client or their systems.
Findings by severity
Broken API authorization on invoice endpoints
Impact: An authenticated integrator account could retrieve and modify invoice objects belonging to other taxpayers by manipulating object identifiers.
Remediation: Enforced server-side object-level authorization on every invoice and taxpayer resource, with deny-by-default checks and regression tests.
Weak protection of API credentials and signing keys
Impact: Integration credentials and cryptographic material were recoverable from configuration and log artefacts, enabling invoice submission impersonation.
Remediation: Moved secrets to a managed vault, rotated all keys, removed secrets from logs, and introduced scheduled rotation.
Missing integrity validation on invoice payloads
Impact: Invoice payloads could be tampered with in transit between the integrator platform and downstream services without detection.
Remediation: Implemented signature verification and canonical payload hashing on both submission and callback paths.
Insecure callback / webhook handling
Impact: Callback endpoints accepted unverified requests, allowing forged status updates for transmitted invoices.
Remediation: Added mutual TLS plus HMAC verification, source allow-listing, and replay protection with nonce and timestamp windows.
Injection and input-validation gaps in taxpayer onboarding
Impact: Unvalidated fields in onboarding workflows created injection risk against backing data stores.
Remediation: Introduced strict schema validation, parameterised queries, and output encoding across all onboarding services.
Session and multi-factor weaknesses in the admin console
Impact: Long-lived sessions and optional MFA on privileged accounts widened the blast radius of a credential compromise.
Remediation: Enforced MFA on all privileged roles, shortened session lifetimes, and added re-authentication for sensitive actions.
Insufficient rate limiting and abuse controls
Impact: Submission and lookup APIs could be enumerated or flooded, risking service degradation during peak filing periods.
Remediation: Applied per-tenant rate limits, quota enforcement, and anomaly alerting on submission volumes.
Cloud and container misconfiguration
Impact: Over-permissive IAM roles, exposed management interfaces, and containers running as root increased lateral-movement risk.
Remediation: Applied least-privilege IAM, restricted management planes to private networks, and hardened container baselines.
Gaps in logging, monitoring, and audit trail
Impact: Security-relevant events on invoice transmission were not consistently logged, hampering incident reconstruction.
Remediation: Standardised structured audit logging with tamper-evident retention and alerting on anomalous access.
Engagement Timeline
Seven weeks from kickoff to a re-test-verified attestation letter.
- Week 0
Scoping & rules of engagement
Confirmed integration architecture, environments, test accounts, data-handling rules, and NRS-specific compliance objectives. Signed NDA and ROE.
- Week 1
Reconnaissance & attack-surface mapping
Enumerated internet-facing assets, API surfaces, authentication flows, and third-party dependencies across the integration stack.
- Weeks 1–2
Manual exploitation & API abuse testing
Senior-led testing of authorization, invoice integrity, callback handling, tenancy isolation, and business-logic abuse — automated scanning used only for coverage, never for conclusions.
- Week 2
Cloud, container & configuration review
Reviewed IAM, network exposure, secrets management, and container baselines supporting the integration platform.
- Week 3
Reporting & remediation workshop
Delivered an executive summary plus reproducible technical findings, then ran a live walkthrough with engineering to sequence fixes.
- Weeks 4–6
Remediation support
Answered engineering questions, reviewed proposed fixes, and validated designs before implementation.
- Week 7
Free re-test & attestation
Re-tested every Critical and High finding, confirmed closure, and issued a summary attestation letter suitable for regulator and enterprise buyer review.
Measurable Outcomes
- Every Critical and High finding closed and independently verified during the included free re-test.
- Cross-tenant data exposure eliminated: authorization is now enforced server-side on every invoice and taxpayer object.
- Invoice integrity assured end to end through payload signing, callback verification, and replay protection.
- Credential and key handling moved to a managed vault with rotation, removing secrets from logs and configuration.
- Audit trail for invoice transmission made complete and tamper-evident, supporting incident response and regulator queries.
- A summary attestation letter issued for use in certification, enterprise security reviews, and RFP responses.
Figures reflect this single engagement and are not a guarantee of outcomes for other organisations. Certification decisions rest with the relevant authority.
Preparing for NRS integration certification?
Book a free scoping call and we'll map exactly what your assessment needs to cover — and how long it will take.