PS Product SecurityKnowledge Base

⚛️ Node.js, Next.js, and React Security Review Guide

Intro: JavaScript-heavy stacks move quickly and make it easy to blur boundaries between browser trust, server trust, and build-time trust. This guide gives reviewers a stack-aware way to catch the mistakes that generic checklists miss.

What this page includes

  • high-value review areas for Node.js services and Next.js applications
  • React and rendering anti-patterns that create security debt
  • common release blockers and fast remediation ideas
  • code-review prompts engineers can use directly

Review the execution model first

For each feature, identify whether the logic runs in:

  • the browser;
  • Node.js server runtime;
  • edge or middleware layer;
  • build time or static generation pipeline.

Security decisions change depending on where the code actually executes.

Node.js backend review focus

Look for:

  • unsafe direct trust in req.headers, proxies, or forwarded origins;
  • weak request validation and schema drift;
  • direct object access by user-supplied IDs without ownership re-check;
  • dependency and package-trust drift in server-side code;
  • event-loop blocking, dangerous regex, or archive/parser abuse in request paths;
  • permissive debug or introspection endpoints;
  • secret exposure through error handling or logging;
  • over-broad internal HTTP clients and SSRF exposure.

Next.js and React review focus

Look for:

  • secrets accidentally loaded into client bundles through public environment variables or shared config;
  • inconsistent header policy between routes, middleware, and asset paths;
  • unsafe rendering patterns such as dangerouslySetInnerHTML without tight sanitization rationale;
  • caching mistakes that can leak personalized responses;
  • authorization assumptions based on client-side route guards;
  • CSP or nonce handling that breaks across rendering modes.

Code-review prompts

  • Does this code move sensitive state into the browser for convenience?
  • If a user changes this identifier, what server-side check stops cross-tenant access?
  • Could this page be cached for the wrong user?
  • Does this feature rely on a third-party script or SDK to touch authenticated state?
  • Is this upload, preview, or export path safe if fully scripted?

Typical release blockers

  • bearer tokens or secrets stored broadly in browser storage;
  • new API route missing ownership checks;
  • admin-only function enforced only in frontend logic;
  • CSP exception added without documented owner or sunset;
  • support or analytics script added to high-sensitivity pages without explicit approval.

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.