This post is not a compliance checklist. It is the practical baseline. The goal is to reduce obvious attack paths before you start talking about advanced detection, red teaming, or zero trust architecture.
Core principle
Security is mostly boundary management. Know what runs in the browser, what runs on the server, what the OS can reach, and who is allowed to touch each layer.
Do these things by default
Keep secrets server-side
API keys, tokens, database credentials, and signing secrets belong on the server only.
Patch packages and base OS
React packages, Next.js dependencies, Node runtime versions, and Linux packages all need a patching rhythm.
Use least privilege
Your app process should not run as root. Your deployment user should not have broad shell access.
Protect admin paths
Put real authentication, authorization, and preferably network restrictions in front of internal tools.
Do not do these things
Do not trust the client
Validation, authorization, pricing logic, and sensitive actions still belong on the server.
Do not expose environment variables carelessly
If a variable is intended for client use, assume users can see it.
Do not assume framework defaults equal security
Next.js gives structure, not immunity.
Do not SSH into production for routine work
Manual hot fixes create drift, weak auditability, and fragile recovery.
Watch these areas in Next.js, React, and Linux
Next.js
Review route handlers as if they were normal backend endpoints. Verify auth on every sensitive route and audit what gets serialized to the client.
React
Avoid dangerous HTML injection unless you fully control the source and sanitize it properly. Do not rely on hidden buttons or client-side flags as authorization.
Linux
Harden SSH, restrict ports, run services as non-root users, patch the system, and keep the firewall stance intentional.