Shivam

Posted on May 18

How We Handle Encrypted Database Fields in a Next.js App

#fledgr #fledgrapp #collegewritingplatform

When we started building Fledgr, we knew pretty early that some data needed stronger protection than a locked-down database alone could provide.

Things like:

UPI IDs
Placement package figures
Anonymous post content

If a database dump ever leaked, we didn’t want sensitive information sitting there in readable form.

That led us to implement field-level encryption.

The Core Idea

Instead of using one static encryption key everywhere, we derive a unique key per field using HKDF.

That means the encryption key for a user's UPI ID is cryptographically separate from the key used for placement data or anonymous content — even though they all originate from the same master secret.

Every sensitive field gets its own context string:

db:users:upiId
db:placements:package
anon:posts:2025-01-15

The nice part is that we never store these derived keys. They’re generated only when needed.

Encryption Flow

export function encrypt(value: string, context: string): string {
  const key = deriveKey(context);
  const iv = randomBytes(12);

  const cipher = createCipheriv("aes-256-gcm", key, iv);

  const encrypted = Buffer.concat([
    cipher.update(value, "utf8"),
    cipher.final(),
  ]);

  const tag = cipher.getAuthTag();

  return Buffer.concat([iv, tag, encrypted]).toString("base64");
}

We use:

AES-256-GCM for authenticated encryption
Random 12-byte IVs
HKDF-derived contextual keys

This keeps encryption isolated across different parts of the system.

Handling Old Plaintext Data

Rolling out encryption in production usually means dealing with legacy rows that were stored before encryption existed.

We didn’t want migrations causing crashes or corrupting data, so every decrypt operation goes through a safe wrapper.

If decryption fails, we simply return the original value instead of throwing an error.

That allowed us to gradually migrate older data without downtime or breaking existing records.

Querying Encrypted Fields

One challenge with encrypted data is querying it.

You can’t directly run WHERE email = ... against encrypted values because encryption output changes every time.

To solve that, we use blind indexes.

For searchable fields like college emails, we store:

The encrypted value
A separate HMAC-based hash column

All lookup queries run against the hash instead of the encrypted field itself.

email_hash = HMAC_SHA256(email)

The actual encrypted value is never used inside query conditions.

What This Actually Protects Against

Field-level encryption is not a replacement for proper secret management.

If the master secret leaks, everything downstream is compromised too.

But that wasn’t the primary threat model we were solving for.

The goal was protecting against database-level exposure:

Misconfigured backups
Leaked database dumps
Overprivileged read replicas
Snapshot exposure
Internal read-only access gone wrong

Those are realistic risks for modern applications, and field-level encryption helps reduce the blast radius significantly.

Performance Impact

We’ve been running this setup in production at Fledgr with almost no noticeable overhead.

The derive-on-demand approach is lightweight enough that users never feel it, while still giving us much stronger isolation for sensitive data.

For us, it ended up being one of those rare security improvements that added meaningful protection without making development harder.

DEV Community