Next.js penetration testing: Security assessment for React server applications

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs Comprehensive Security Partner (CSP)

Why Next.js applications fail security tests

Developers love Next.js because it makes building full-stack applications fast. It handles routing. It handles API endpoints. It handles server-side rendering. But speed creates blind spots.

The core problem is the trust boundary. In older frameworks like Django or Ruby on Rails, the server and the client lived in two different worlds. You knew exactly where the backend stopped and the frontend started. Next.js destroys that boundary. You can write a database query right next to a React button component.

If a developer forgets exactly where that code executes, they expose your entire database to the public internet. Automated scanners do not understand React Server Components. Scanners do not understand Server Actions. You need manual penetration testing by engineers who write React code. We understand exactly how Next.js works under the hood. We find the flaws that scanners miss.

1. Server Actions authorization testing

Server Actions are async functions defined with the 'use server' directive. When called from a Client Component, Next.js exposes them as HTTP POST endpoints with a generated URL. The key finding we look for is Server Actions that perform data mutations without verifying the current user's authorization:

// VULNERABLE Server Action: no authorization check
'use server'

export async function updateUserTier(userId: string, tier: number) {
  // Flaw: any authenticated user can upgrade any other user's tier
  await db.user.update({ where: { id: userId }, data: { tier } });
}

We call every Server Action directly using HTTP POST requests crafted in Burp Suite, bypassing the React component UI. This confirms whether authorization is enforced at the action layer or only in the client-side component logic that invokes it (which is trivially bypassed).

Many developers assume that if they hide a button in the UI, the Server Action attached to that button is safe. This is false. The endpoint still exists. We extract the action IDs from your Javascript bundle. We send raw POST requests to those endpoints. We test every single Server Action for Broken Object Level Authorization (BOLA). We prove exactly how an attacker escalates privileges without ever touching your user interface.

2. Next.js middleware bypass

Next.js middleware runs at the edge before a request reaches a page or API route. It is commonly used to check session cookies and redirect unauthenticated users. A critical class of bypass occurs when the middleware matches routes using string patterns that do not cover all routes that need protection.

We have found cases where middleware protected /dashboard but not /dashboard.json, /dashboard/ (trailing slash), or API routes under the dashboard path that return the same sensitive data.

We map your entire application routing structure. We fuzz the URL paths. We add special characters, alternate file extensions, and casing variations. We attack the regex patterns in your middleware configuration. If your middleware checks for starts_with('/admin'), we try to access /Admin or /admin-api. We find the exact URL string that bypasses your edge protection and grants us direct access to your private pages.

3. Environment variable exposure in client bundles

We inspect every Next.js production build's client-side JavaScript chunks for NEXT_PUBLIC_ prefixed variables. Finding a variable like NEXT_PUBLIC_PAYSTACK_SECRET_KEY in a production bundle is a critical finding that requires immediate remediation.

We also inspect next.config.js for the env block, which can inadvertently expose server-only variables to the client runtime if the configuration is authored incorrectly. Developers copy and paste configuration snippets from Stack Overflow. They accidentally expose their AWS IAM keys or their MongoDB connection strings to the public.

We download your compiled Webpack bundles. We use reverse engineering tools to extract all the hardcoded strings. We map every single key we find. We verify if the key belongs on the client or the server. If we find a server key on the client, we use it to demonstrate a direct attack on your infrastructure.

4. API Route authorization

Next.js API routes (under pages/api/ or app/api/) are HTTP endpoints. We test every API route for: missing authentication middleware, Broken Object Level Authorization (where one user can fetch another user's data by changing an ID parameter), HTTP method restrictions (does a GET-only route accept POST requests?), and rate limiting enforcement on high-frequency sensitive endpoints.

Next.js makes it very easy to build APIs fast. Developers often skip building a centralized authentication wrapper. They just write the logic directly in the route file. They forget to check if the user actually owns the data they requested. We intercept your API traffic. We change the JSON payloads. We test if User A can delete User B's profile. We lock down your backend services.

5. Incremental Static Regeneration (ISR) cache poisoning

ISR allows Next.js pages to regenerate statically in the background. If a page's static regeneration path includes user-controlled data (such as a user profile slug that renders into a statically cached page), an attacker may be able to manipulate a cached page's content.

We test ISR-enabled pages for paths where the cached output includes data derived from untrusted input sources. We inject malicious Javascript payloads into the data source. We trigger a background rebuild. If your Next.js server pulls our malicious data and caches it into the static HTML file, every subsequent visitor gets attacked automatically. This is a severe form of Stored Cross-Site Scripting (XSS). We find it, and we help you implement strict output sanitization.

6. Server-Side Request Forgery (SSRF) in Next.js Image Optimization

Next.js includes a powerful built-in Image component. This component fetches images from external URLs and optimizes them on your server. If you configure the remotePatterns in your next.config.js file poorly, you create a massive vulnerability.

We attack the image optimization endpoint directly. We trick your Next.js server into fetching data from its own internal network instead of a public image URL. We force your server to read internal AWS metadata. We force your server to port-scan your internal database. We prove exactly how a simple image tag turns into a full network breach.

The Simpa Labs reporting standard

We do not leave you alone to fix the mess. We give your engineering team the exact tools they need to secure the Next.js platform quickly and permanently.

You receive a massive, detailed technical report. We provide the exact HTTP request logs from Burp Suite. We write out the exact steps to reproduce the attack. Your engineers can copy our steps and watch the bug happen on their own local development servers.

We give you precise code snippets to fix the flaws. We show you how to implement strict server-side validation for all Server Actions. We show you how to write bulletproof middleware configurations. We teach you the correct way to handle environment variables in the App Router.

Related reading

Blog: Next.js Server Actions deep dive · React SPA security testing · API data leaks

Services: Penetration testing · API security testing