How I enforced rate limits in Next.js without ever storing an IP address

Rate limiting a voting system requires a stable identifier for each visitor. The obvious choice is the IP address. The problem: storing IP addresses is a GDPR liability. They are personal data in most EU interpretations. You need them for rate limiting but you should not keep them in plaintext — not in Redis, not in the database, not in logs.

One-way hashing with a secret salt

The solution is SHA-256 with a secret salt, truncated to 32 hex characters. The hash is deterministic — the same IP always produces the same hash — so you can use it as a stable rate-limit key. But it is not reversible. Given the hash, you cannot recover the original IP. The salt makes it resistant to rainbow table attacks.

// lib/utils.ts
import crypto from 'crypto';

export function hashIP(ip: string): string {
  return crypto
    .createHash('sha256')
    .update(ip + process.env.IP_HASH_SALT)
    .digest('hex')
    .slice(0, 32);
}

// lib/utils.ts — reading the real client IP from Next.js headers
export function getClientIP(request: Request): string {
  const headers = new Headers(request.headers);
  return (
    headers.get('x-real-ip') ??
    headers.get('x-forwarded-for')?.split(',')[0].trim() ??
    '127.0.0.1'
  );
}

Two separate salts for two separate purposes

AI Art Arena uses two hash salts. IP_HASH_SALT is used for IP addresses throughout the application. VOTE_HASH_SALT is used exclusively for hashing email addresses into the votes table as a third duplicate-vote detection layer. They are separate environment variables deliberately: if one is compromised, the other is not affected. Using a single shared salt would mean a single leaked secret breaks both protections simultaneously.

Why the salt can never change after launch

This is the constraint that is easy to miss until it is too late. The salt is a secret input to a one-way hash. Every existing hash in the system was produced using the current salt. If you change the salt, all existing hashes become orphaned — the new salt produces different hashes for the same inputs, so the system cannot match a new vote attempt against existing vote records.

The env var file has a comment that reads: 'Generate once with openssl rand -base64 32. Never change after the first vote is cast.' That comment is not convention — it is a hard constraint. Rotating the salt is equivalent to deleting your vote history.

The sliding window vs fixed window decision

Upstash Ratelimit offers both fixed window and sliding window algorithms. Fixed window has an exploitable boundary: vote at 11:59pm, vote again at 12:00am — two votes in two minutes, both within their respective windows. Sliding window tracks the rolling 24 hours and has no such boundary. For a system where one vote per contest is the core integrity guarantee, fixed window is not acceptable. All five rate limiters in this project use sliding window.

From the build log