It was not the blockchain that failed. It was the Node.js API talking to it.

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

The real architecture of a Nigerian crypto exchange

Most crypto platforms operating in Nigeria — whether processing retail P2P trades or facilitating corporate treasury transfers — share a common structural blueprint. The architecture is split into four distinct zones:

• User-Facing Apps: The iOS, Android, and web frontends built with Flutter, React Native, or Next.js. These apps do not talk to the blockchain. They interface directly with the exchange order book backend via REST or WebSockets.
• The Order Book Backend: Typically a Node.js (NestJS or Express) or Django application. It manages user balances, processes buy/sell matches, handles database records, and initiates deposit and withdrawal requests.
• The Hot Wallet Service: A dedicated, internal microservice that manages private keys and initiates blockchain transactions. It connects to custody APIs like Fireblocks or BitGo, or talks directly to self-hosted blockchain nodes (such as an Ethereum Geth node or Bitcoin Core node via JSON-RPC). This service holds only 10% to 20% of the exchange's liquid assets to cover daily withdrawals.
• The Cold Wallet: Air-gapped, multi-signature addresses that hold the remaining 80% to 90% of customer assets. Transferring funds from cold to hot wallets requires manual, offline approval from multiple key custodians.

The blockchain itself is immutable. The real attack surface is the API bridge — the communication channel between the order book backend and the hot wallet service. If an attacker compromises this bridge, they can issue withdrawal instructions to the hot wallet as if they were the backend ledger itself.

Vulnerability 1: Hot wallet API key exposure

The order book backend must authenticate itself to the hot wallet service or custody provider (like the Fireblocks API or BitGo API). This authentication relies on static API keys or private signing keys. If these credentials leak, the hot wallet is exposed.

In many Nigerian crypto startups, we find keys hardcoded in code, left in .env files committed to private GitHub repositories, or logged in cleartext. If an attacker gains access to your repository (via a developer's compromised personal GitHub account) or reads your container logs via a secondary SSRF or LFI vulnerability, they obtain the credentials.

Another common vector is shipping secrets to the client. During a client-side bundle generation (e.g., using Webpack or Vite), developers sometimes accidentally prefix environment variables with PUBLIC_ or NEXT_PUBLIC_. This bundles the hot wallet API key directly into the JavaScript files downloaded by every mobile or web user.

// VULNERABLE: Environment variable exposure in logs
try {
  const response = await axios.post(
    'https://api.fireblocks.io/v1/transactions',
    payload,
    { headers: { 'X-API-Key': process.env.FIREBLOCKS_API_KEY } }
  );
} catch (error) {
  // This dumps the entire request config, including the API key, into production logs
  logger.error("Fireblocks transaction failed", error);
}

Once an attacker extracts this key, they do not need to exploit the exchange frontend or database. They can make direct requests to the custody API, signing and executing withdrawal transactions that drain the hot wallet.

Vulnerability 2: SSRF to internal wallet service

To prevent public exposure, exchanges run their hot wallet RPC nodes or wallet microservices on internal private networks (e.g., localhost:8545 for an Ethereum node, or http://wallet-service.internal). Because these services are internal, developers often omit authentication, assuming the network perimeter is sufficient protection.

An attacker can bypass this perimeter using a Server-Side Request Forgery (SSRF) vulnerability. This typically occurs in features that fetch external URLs, such as custom webhook configurations, user profile avatar uploaders, or payment callback handlers that verify Flutterwave or Paystack transactions.

If the backend does not validate or sanitize the target URL, the attacker can force the backend server to make an HTTP request to an internal address. The internal wallet service receives the request, sees that it comes from the local network, and executes the transfer without verifying if the user has authorization.

// Vulnerable web callback endpoint allowing SSRF
POST /api/v1/webhooks/payment-callback
Content-Type: application/json

{
  "callback_url": "http://127.0.0.1:8545"
}

If the backend processes the raw URL in the payload, the node will POST JSON-RPC payloads directly to the internal Ethereum daemon, calling personal_sendTransaction to drain the hot wallet.

Vulnerability 3: Unprotected internal withdrawal API

The order book backend needs an endpoint to tell the wallet service to execute a payout. This is often an internal route like POST /internal/wallet/withdraw.

We frequently find that this endpoint is exposed to the public internet because of misconfigured Nginx or API gateway rules. For example, a wildcard rule routing all /api/* traffic to the backend may accidentally expose /api/internal/* or /api/v1/internal/*.

Furthermore, because developers assume this endpoint is "internal-only," they may secure it with a static, hardcoded authorization token in the code, or omit authentication completely. An attacker scanning the domain's public ports can discover this endpoint and send a POST request with their wallet address, bypassing the user's ledger check and draining the hot wallet directly.

// Example raw HTTP request exploiting an exposed internal route
POST /api/v1/internal/withdraw HTTP/1.1
Host: api.nigeriancryptoexchange.com
Content-Type: application/json

{
  "currency": "USDT",
  "amount": 50000,
  "destination": "0xAttackersEthereumAddress..."
}

Vulnerability 4: P2P release logic manipulation

Peer-to-peer (P2P) trading is the primary liquidity engine for Nigerian crypto exchanges due to Central Bank of Nigeria (CBN) restrictions on direct crypto banking. The typical escrow workflow runs as follows: the buyer initiates a purchase → the exchange locks the seller's crypto in escrow → the buyer pays Naira to the seller's bank account → the buyer marks the order as paid → the seller confirms the receipt of funds → the exchange releases the crypto to the buyer.

The vulnerability lies in how the backend processes the "seller confirms receipt" state. In weak implementations, the endpoint that releases the escrowed crypto only checks if the request is authenticated, but fails to verify if the request was actually signed by the seller of that specific order.

An attacker can create a buy order, wait for the escrow to lock, and then call the release endpoint programmatically by spoofing the transaction ID. If the backend fails to validate that the caller's ID matches the seller's ID for that specific transaction, the system releases the crypto to the attacker without the seller ever receiving Naira.

// Vulnerable release endpoint pattern
POST /api/v1/p2p/release
Content-Type: application/json
Authorization: Bearer <ATTACKER_JWT>

{
  "order_id": "9a2f8b1c-d3e4-4a5b-8c9d-0e1f2a3b4c5d"
}

If the backend checks req.user.id is active but fails to verify that the owner of order_id's seller field is indeed the user executing the request, the release completes immediately.

Why Nigerian exchanges are specifically targeted

Nigerian crypto platforms operate in a unique and high-stress environment that makes them primary targets for cybercriminals.

First, regulatory ambiguity plays a major role. Although the SEC Nigeria has issued Digital Assets Rules, compliance enforcement remains fragmented, and incident disclosure is often informal. Unlike traditional banks, crypto startups are reluctant to report breaches to law enforcement or regulators like the National Information Technology Development Agency (NITDA) due to fear of losing their operating licenses or user base.

Second, international blockchain analytics companies track funds, but the legal and law enforcement response in Nigeria is slow. Once funds are moved to local bank accounts through P2P merchants or swapped on cross-border platforms, recovery becomes difficult.

Third, many Nigerian crypto startups are bootstrapped. They scale quickly, handling tens of millions of dollars in transaction volume, but underinvest in security infrastructure. A platform processing ₦1 billion in monthly volume might have zero dedicated security engineers, relying entirely on full-stack developers who are focused on shipping features.

The architectural fix

Securing a crypto exchange requires structural network isolation and cryptographic validation. You need to implement these changes:

• HSM and Secrets Management: Store all hot wallet API keys, custody credentials, and private signing keys in a hardware security module (HSM) or a managed secrets service like AWS Secrets Manager or HashiCorp Vault. Never use plain text environment variables on application servers. Implement automatic monthly credential rotation.
• Strict Network Isolation: Place the hot wallet service inside an isolated private subnet within your Virtual Private Cloud (VPC). Block all inbound internet traffic. The service must only accept connections from the IP address of the order book backend.
• mTLS Authentication: Implement mutual TLS (mTLS) between your order book backend and the hot wallet service. Every API call must be authenticated using client-side certificates, guaranteeing that even if an attacker gains access to the internal network, they cannot communicate with the wallet service without the correct client certificate.
• Independent Payment Verification: For P2P release flows, never rely on client-side state flags. Before releasing crypto from escrow, verify payment status using bank statement APIs or webhook confirmations from payment gateways like Paystack or Flutterwave. Additionally, validate cryptographically that the request to release funds matches the seller's user ID.
• Withdrawal Destination Whitelists: Enforce destination address whitelisting. Any user or system-level request to add a new withdrawal address must pass a mandatory 24-hour waiting period and require multi-factor authentication (MFA) before any funds can be sent to it.

Related reading

Blog: Hardcoded API keys in mobile apps · Securing AWS infrastructure for fintechs

Services: API security testing · Penetration testing · Secure architecture review