Security — NexChat

End-to-End Encryption
Authentication & JWT Security
OTP Verification
Rate Limiting
Input Validation
Security Headers
Block & Report System
Infrastructure Security

End-to-End Encryption

NexChat implements a public key infrastructure (PKI) for end-to-end encryption. Each user generates a public-private key pair. The public key is stored on the server and shared with other users, while the private key never leaves the client device.

How it works: When User A wants to send a message to User B, the client fetches User B's public key, encrypts the message locally, and sends only the ciphertext. Only User B's private key can decrypt it — the server never sees plaintext content.

Public keys can be saved and retrieved via the /api/users/public-key endpoints. In production, this enables true zero-knowledge encryption where even NexChat's infrastructure cannot read your messages.

Authentication & JWT Security

NexChat uses a dual-token JWT strategy for secure, session-based authentication:

Access Token — Short-lived (15 minutes). Signed with a secret key and contains the user's ID, email, and phone. Sent with every API request via the Authorization: Bearer header.
Refresh Token — Long-lived (30 days). Stored in the database and used exclusively to obtain new access tokens without requiring re-login.
Token Rotation — Each time a refresh token is used, it is revoked and a new one is issued. If a stolen refresh token is used after the legitimate owner has already rotated it, the stolen token becomes invalid immediately.

The client-side Axios interceptor automatically detects 401 responses, queues concurrent failed requests, refreshes the token, and retries — all without interrupting the user experience.

OTP Verification

NexChat supports one-time password (OTP) verification via email (Resend API / Nodemailer SMTP) or SMS (Twilio). This can be configured as a mandatory step before registration and login.

6-digit code — Generated server-side using cryptographically random values.
5-minute TTL — Codes expire after 5 minutes and are stored in Redis with automatic expiry.
Single-use — Each code is deleted immediately after successful verification.
Verified flag — On successful OTP verification, a 10-minute verified flag is set in Redis to allow the registration or login flow to complete.

Rate Limiting

NexChat uses express-rate-limit to protect the API from abuse:

Global limit: 100 requests per 15 minutes per IP address.
Exceeding this limit returns a 429 Too Many Requests response with a clear error message.
Rate limiting applies to all endpoints including auth routes, preventing brute-force attacks on login, OTP, and token refresh endpoints.

Input Validation

Every request body, query parameter, and route parameter is strictly validated using Zod schemas before reaching the controller logic:

Body validation — validateBody() middleware parses and validates all req.body against a Zod schema.
Query validation — validateQuery() middleware validates URL query parameters.
Params validation — validateParams() middleware validates route parameters like conversation IDs.
Invalid requests receive a descriptive 400 Validation Error response with field-level error details.

Zod validation prevents injection attacks, type confusion, and malformed payloads from reaching your database or business logic.

Security Headers

NexChat applies Helmet — a collection of 15+ middleware functions that set security-related HTTP headers:

Content-Security-Policy — Prevents XSS attacks by controlling allowed content sources.
X-Content-Type-Options — Prevents MIME type sniffing.
X-Frame-Options — Prevents clickjacking by disabling iframe embedding.
Strict-Transport-Security — Enforces HTTPS connections (when deployed with TLS).
X-DNS-Prefetch-Control, X-Download-Options, and more.

Block & Report System

NexChat provides a comprehensive moderation system:

Block users — Blocked users cannot send you messages. The block is a unique composite key (blockerId, blockedId) ensuring no duplicate blocks.
Self-block prevention — You cannot block yourself.
Message send check — Before a message is sent, the server checks both directions: whether the sender is blocked by the recipient, and whether the recipient is blocked by the sender.
Report system — Users can be reported with a reason and optional description for moderation review.

Infrastructure Security

PostgreSQL — Data is stored in a relational database with parameterized queries via Prisma ORM, eliminating SQL injection risks.
Redis — Used for session data, OTP codes, and presence information with short TTLs. No permanent sensitive data stored in cache.
Cloudflare R2 — File storage uses S3-compatible API with presigned URLs for secure, time-limited upload access.
Environment Variables — All secrets (JWT keys, API keys, database URLs) are loaded from environment variables validated by Zod at startup. Invalid config prevents the server from starting.
Docker — Services run in isolated containers with minimal attack surface (Alpine-based images).

NexChat follows security best practices at every layer — from input validation and authentication to infrastructure deployment. We recommend always running the latest version and using HTTPS in production.

Security & Encryption

Contents