Security

Overview

NextBento includes several security measures. Follow these practices when extending the app.

Environment Validation

lib/config/env.ts — Zod schema validates env vars at startup. Ensures required keys are present and correctly formatted. Never trust unvalidated env in production.

Rate Limiting

lib/middleware/rate-limit.ts — IP-based rate limiting on auth endpoints:

• /api/auth/login
• /api/auth/signup
• /api/auth/forgot-password
• /api/auth/reset-password
• /api/auth/magic-link
• /api/auth/change-password

Uses Upstash Redis when UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN are set (Vercel-safe, multi-instance). Otherwise falls back to an in-memory store (fine for local/dev and single-instance deploys).

Prevents brute force and abuse. Extend to other sensitive endpoints as needed.

API Tokens

• API keys are hashed (SHA-256) before storage — plain key shown only on creation
• lib/security/ — Token hashing utilities
• Validate tokens server-side; never trust client-only checks

Gatekeeping

• Every endpoint should verify user identity before returning data
• Don't rely on hiding UI — gate data delivery on the server
• Use Supabase RLS; avoid bypassing RLS from the client

Sensitive Data

• Don't log passwords, tokens, or API keys
• Use vague error messages for users; log details server-side only
• Sanitize all user inputs before storage or display

CORS

lib/middleware/cors.ts — CORS handling for API routes. Configure allowed origins for your domain.

CSP (Content Security Policy)

If you add CSP headers, configure them in next.config.js or middleware. Start with report-only mode to avoid breaking the app.