Next.js
3 articles with this tag
Do Next.js and React Have a Lot of Vulnerabilities? What the CVE Data Actually Shows
The data says React core has almost no CVEs while Next.js CVEs are numerous and rising. What matters is where they are: they land in middleware, caching, image optimization and Server Actions, with SSRF, deserialization and authorization bypass leading the CWEs. This site's conclusion: Next.js should not be treated as only a front-end framework. It runs as a server, so defend it like one: authorize again at the data, allow-list outbound fetches, and put Server Action endpoints behind auth.
Next.js security — a production hardening reference
Next.js's defaults are fairly safe, but incidents happen at the server/client boundary. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — the boundary and env vars (NEXT_PUBLIC_), dependency CVEs (including core RCE), Server Actions / Route Handlers authorization + input validation, SSRF on server-side fetches, security headers/CSP, auth/session/cookies, rate limiting, and (3) a self-verification checklist. Defensive only — no attack steps.
Running Next.js safely: not falling behind on published CVEs
The top framework risk is neglected published CVEs. Defend with four practices: judge by the running version, monitor with Dependabot/osv-scanner, update fast, and run least-privilege. This site's view: what indie devs usually lack is not knowledge but a way to keep operations going; a system that doesn't miss CVEs matters more than speed.