Next.js Security Best Practices: What Your Scanner Misses

Next.js has become the default framework for modern web applications. Its hybrid rendering model, built-in API routes, middleware layer, and seamless deployment to platforms like Vercel make it the natural choice for everything from landing pages to full-scale SaaS products. It's also the framework most commonly generated by AI coding tools — when you build something with Cursor, v0, or Bolt, there's a strong chance the output is a Next.js application.

But Next.js introduces a unique set of security challenges that most conventional vulnerability scanners simply don't understand. This article covers the Next.js-specific security risks that generic scanners miss, why they matter, and how to actually detect and fix them.

Source Map Exposure: Your Entire Codebase is Readable

When Next.js builds your application for production, it can generate source maps — files that map the minified JavaScript served to browsers back to your original source code. If these source maps are publicly accessible (and by default they often are), anyone can reconstruct your entire application's source code.

This isn't just an intellectual property concern. Source maps frequently reveal internal API endpoint patterns, commented-out code that hints at unreleased features, business logic that an attacker can study, and references to internal services and infrastructure.

Fix: Set productionBrowserSourceMaps: false in your next.config.js:

// next.config.js
module.exports = {
  productionBrowserSourceMaps: false,
};

Vuln0x includes a dedicated Source Map Exposure scanner that detects publicly accessible .map files, checks for sourceMappingURL references in served JavaScript, and identifies webpack/Next.js build artifact exposure.

Client-Side Secret Leakage in JavaScript Bundles

Next.js uses environment variable prefixes to control what gets exposed to the browser. Variables prefixed with NEXT_PUBLIC_ are included in the client-side JavaScript bundle; variables without that prefix should only be available on the server side.

The problem occurs in two ways. First, AI code generators sometimes add the NEXT_PUBLIC_ prefix to variables that should remain server-side. Second, developers sometimes access server-only variables in shared components that get rendered on both client and server.

// WRONG: This exposes your secret key to the browser
const stripe = new Stripe(process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY);
// CORRECT: Use server-only variables in API routes
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

Once a secret is in the client bundle, it's permanently exposed. Vuln0x's Client-Side Secret Leakage scanner analyzes JavaScript bundles for API keys, database connection strings, and authentication secrets.

SSRF in API Routes: The Silent Threat

Next.js API routes run on the server, which means they can make outbound HTTP requests. This is a significant attack surface if any user-controlled input influences the URL or destination of those server-side requests.

Server-Side Request Forgery (SSRF) in Next.js API routes can allow an attacker to access internal network resources, cloud metadata endpoints at 169.254.169.254, scan internal services, and bypass firewalls.

// VULNERABLE: User controls the fetch URL
export async function GET(request) {
  const url = request.nextUrl.searchParams.get('url');
  const response = await fetch(url); // SSRF risk!
  return Response.json(await response.json());
}
// SECURE: Validate and whitelist destinations
export async function GET(request) {
  const url = request.nextUrl.searchParams.get('url');
  const parsed = new URL(url);
  const allowedHosts = ['api.example.com'];
  if (!allowedHosts.includes(parsed.hostname)) {
    return Response.json({ error: 'Invalid host' }, { status: 400 });
  }
  const response = await fetch(url);
  return Response.json(await response.json());
}

Authentication Logic Flaws in Middleware

Next.js middleware runs before every request and is commonly used for authentication checks. The most common flaw is incomplete route protection — middleware-based auth checks need to explicitly match every route that requires authentication, and it's easy to miss paths.

// middleware.ts - Make sure ALL protected routes are covered
export const config = {
  matcher: [
    '/dashboard/:path*',
    '/api/:path*',
    '/settings/:path*',
    // Don't forget these!
    '/admin/:path*',
    '/billing/:path*',
  ],
};

XSS in React/Next.js: Not Just dangerouslySetInnerHTML

React's JSX model provides automatic XSS protection for most cases. But there are still vectors:

• dangerouslySetInnerHTML bypasses React's escaping entirely
• Rendering user input inside href attributes can create javascript: protocol XSS
• Server-rendered HTML can introduce XSS before React's client-side protection kicks in
• Third-party React component libraries may have their own XSS vulnerabilities

// VULNERABLE
<a href={userInput}>Click here</a>
// If userInput = "javascript:alert(1)" — XSS!
// SECURE: Validate URL protocol
const safeHref = userInput.startsWith('http') ? userInput : '#';
<a href={safeHref}>Click here</a>

How to Scan for Next.js-Specific Issues

Vuln0x offers 10 specialized scanners designed specifically for Next.js and React applications, plus a dedicated Next.js Full Scan (12 credits) that runs all of them together. For the most thorough assessment, Sentinel — the AI pentest agent — automatically adjusts its attack strategy when it detects Next.js, focusing on framework-specific vectors.

Scan your Next.js app now: Start free with Vuln0x — 20 credits on signup, no credit card required.