HTTPS secures the transport layer — but what happens when your server, proxy, or cloud provider is compromised? Learn how to implement payload-level E2E encryption in Node.js using libsodium.

How to Implement End-to-End Encryption in a Node.js REST API

HTTPS is not end-to-end encryption. This distinction is worth repeating because most development teams stop at TLS, tick the security checklist, and move on. TLS encrypts data in transit between the client and your server — but the moment that data lands on your infrastructure, it is decrypted and readable by anything with access: your application server, a reverse proxy, a logging agent, or an attacker who has quietly gained a foothold on your system.

Real end-to-end encryption (E2EE) means the payload is encrypted before it leaves the client and can only be decrypted by its intended recipient — not your server, not your cloud provider, not a compromised middleware layer. If you are building APIs that handle medical records, financial data, private messages, or any sensitive PII, payload-level encryption is not optional.

This guide walks you through implementing E2EE in a Node.js REST API using libsodium, a modern, battle-tested cryptographic library that makes it genuinely hard to do the wrong thing.

Why libsodium Over the Built-in `crypto` Module?

Node.js ships with a crypto module, and it is perfectly capable. But it exposes a large surface area of algorithms — many of which are outdated (MD5, DES, ECB mode AES). Picking the right combination of algorithm, key size, IV strategy, and padding requires expert knowledge. One wrong decision silently undermines your entire security model.

libsodium (and its Node.js wrapper, libsodium-wrappers or the higher-level tweetnacl) takes an opinionated approach: it bundles best-practice primitives — X25519 for key exchange, XSalsa20 for encryption, Poly1305 for authentication — into a single, hard-to-misuse API. You get authenticated encryption by default. There is no way to accidentally use a stream cipher without a MAC.

The Architecture: How Payload E2EE Works in a REST Context

Before writing a line of code, understand the model:

Client generates an ephemeral key pair (public + secret key) per session or per request.
Server has a long-term public key that is distributed to clients (embedded in the app, fetched at startup, or pinned).
Client encrypts the payload using the server's public key and its own ephemeral secret key via X25519-XSalsa20-Poly1305 (libsodium's box).
Client sends the encrypted payload plus its ephemeral public key in the request.
Server decrypts using its secret key and the client's ephemeral public key.
Server encrypts the response using the client's ephemeral public key, so only that client session can read it.

This model ensures that even if a proxy logs the raw request body, it sees only ciphertext. Even if your database is breached and contains stored payloads, they are unreadable without the server's secret key — which should live in a secrets manager, not in your application's environment flat file.

Setting Up libsodium in Node.js

npm install libsodium-wrappers

import _sodium from 'libsodium-wrappers';

async function getSodium() {
  await _sodium.ready;
  return _sodium;
}

// Generate the server's long-term key pair (do this once, store securely)
async function generateServerKeyPair() {
  const sodium = await getSodium();
  const keyPair = sodium.crypto_box_keypair();
  return {
    publicKey: sodium.to_base64(keyPair.publicKey),
    secretKey: sodium.to_base64(keyPair.privateKey), // Store in a secrets manager
  };
}

// Server-side decryption of an incoming encrypted payload
async function decryptPayload(encryptedData, clientPublicKeyB64, serverSecretKeyB64) {
  const sodium = await getSodium();

  const clientPublicKey = sodium.from_base64(clientPublicKeyB64);
  const serverSecretKey = sodium.from_base64(serverSecretKeyB64);
  const { nonce, ciphertext } = encryptedData;

  const decrypted = sodium.crypto_box_open_easy(
    sodium.from_base64(ciphertext),
    sodium.from_base64(nonce),
    clientPublicKey,
    serverSecretKey
  );

  return JSON.parse(sodium.to_string(decrypted));
}

// Server-side encryption of a response back to the client
async function encryptResponse(payload, clientPublicKeyB64, serverSecretKeyB64) {
  const sodium = await getSodium();

  const clientPublicKey = sodium.from_base64(clientPublicKeyB64);
  const serverSecretKey = sodium.from_base64(serverSecretKeyB64);
  const nonce = sodium.randombytes_buf(sodium.crypto_box_NONCEBYTES);

  const ciphertext = sodium.crypto_box_easy(
    JSON.stringify(payload),
    nonce,
    clientPublicKey,
    serverSecretKey
  );

  return {
    nonce: sodium.to_base64(nonce),
    ciphertext: sodium.to_base64(ciphertext),
  };
}

Wiring It Into an Express Route

With the crypto helpers in place, integrating them into a route is straightforward. The pattern is: decrypt the request body early, process business logic, encrypt the response before sending.

app.post('/api/secure-data', async (req, res) => {
  const { encryptedPayload, clientPublicKey } = req.body;

  const payload = await decryptPayload(
    encryptedPayload,
    clientPublicKey,
    process.env.SERVER_SECRET_KEY
  );

  // ... process payload, run business logic ...

  const responseData = { status: 'success', result: 'processed' };
  const encryptedResponse = await encryptResponse(
    responseData,
    clientPublicKey,
    process.env.SERVER_SECRET_KEY
  );

  res.json({ encryptedResponse });
});

For cleanliness, abstract the decrypt/encrypt steps into an Express middleware so your route handlers never touch raw ciphertext.

Key Management: Where Most Teams Get It Wrong

The strongest cryptographic implementation collapses if key management is poor. A few firm guidelines:

Never store the server secret key in .env files committed to version control. Use a dedicated secrets manager: AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager.
Rotate keys periodically. Design your client to fetch the server's current public key at startup and handle a key-rotation response gracefully.
Use ephemeral client keys per session, not per user account. This provides forward secrecy — compromising one session key reveals nothing about past or future sessions.
Authenticate clients before trusting their public key submissions. E2EE does not replace authentication. Use JWT or mutual TLS to verify who is sending the encrypted payload.

What About the Client Side?

libsodium-wrappers runs in the browser via WebAssembly and in React Native via compatible polyfills. The client-side flow mirrors the server: generate an ephemeral key pair, encrypt the payload with the server's public key, attach the ephemeral public key to the request. For mobile apps written in Swift or Kotlin, equivalent libsodium bindings (swift-sodium, lazysodium-android) provide the same primitives.

Limitations to Be Honest About

E2EE at the payload level does not protect against:

A compromised client. If the device is rooted or malware has access to memory, the plaintext is exposed before encryption.
Server-side logic vulnerabilities. After decryption, your application code handles plaintext. SQL injection, insecure deserialization, and IDOR vulnerabilities are still your problem.
Metadata leakage. Payload contents are encrypted, but request timing, size, and endpoint patterns can still leak information.

E2EE is one layer in a defence-in-depth strategy, not a replacement for the rest of it.

Why This Matters for Your Project

If you are building a SaaS product that touches sensitive user data — healthcare, fintech, legal tech, or enterprise collaboration — payload-level encryption is increasingly a compliance expectation, not just a best practice. Regulations like GDPR, HIPAA, and Ghana's Data Protection Act demand that you demonstrate data is protected even when your systems are compromised. Implementing E2EE with a well-audited library like libsodium is one of the most concrete steps you can take to meet that bar, reduce breach liability, and ship software that your users can genuinely trust.