A Wildcard in Your next.config Image remotePatterns Might Turn Your Site Into an SSRF Proxy

#security #nextjs #typescript #webdev

next/image optimizing external images is genuinely convenient, resizing, format conversion, all handled automatically through Next.js's built-in image optimization endpoint. That endpoint fetches the remote image server-side before serving the optimized version to the browser, and that server-side fetch is exactly the mechanism that becomes a real problem if remotePatterns is configured too loosely.

The Configuration That Looks Convenient

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: '**', // "just let any https image load, easier than maintaining a list"
      },
    ],
  },
};

This shows up constantly, especially on projects where images come from a genuinely wide variety of sources, user-uploaded content pointing at various CDNs, a CMS that could reference images from anywhere. The wildcard hostname feels like a reasonable convenience, avoid maintaining an explicit allowlist, just accept any https image URL.

Why This Is Actually a Real Vulnerability

Next.js's image optimization endpoint, /_next/image, accepts a url parameter and fetches it server-side. With hostname: '**', that endpoint will fetch essentially any URL an attacker provides, as long as it's https. This turns your own server into a general-purpose URL-fetching proxy, controllable by anyone who can construct a request to that endpoint, which is a textbook Server-Side Request Forgery setup.

https://yoursite.com/_next/image?url=https://internal-admin-panel.yourcompany.com/&w=640&q=75

If your infrastructure has any internal services reachable from where your Next.js app runs, an internal admin panel, a cloud metadata endpoint, an internal API with no separate auth layer because it was assumed to only be reachable from inside your own network, a wildcard remotePatterns configuration means your own server will happily make that request on an attacker's behalf and, depending on exactly how the endpoint's response gets exposed, potentially leak some information about what came back.

The Specific, Well-Known Version of This: Cloud Metadata Endpoints

This is the classic SSRF target, and it's directly relevant here. Most cloud providers expose an internal metadata endpoint, http://169.254.169.254/, reachable only from within their own infrastructure, that can return real credentials or configuration data for the running instance. A wildcard image proxy is exactly the kind of mechanism that's been used in real-world SSRF attacks to reach exactly this endpoint from inside cloud environments, since the request originates from your own server, which does have network access to it, not from the attacker's machine, which doesn't.

The Fix: An Actual Allowlist, Not a Wildcard

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'res.cloudinary.com',
      },
      {
        protocol: 'https',
        hostname: 'yourbucket.s3.amazonaws.com',
      },
      {
        protocol: 'https',
        hostname: 'lh3.googleusercontent.com', // if accepting Google account avatars, for example
      },
    ],
  },
};

An explicit list of the actual, known image sources your app legitimately uses closes this off entirely. The image optimization endpoint will only fetch from hosts on this list, regardless of what URL parameter someone tries to pass in, which is the entire point, the server should only ever be willing to fetch from sources you've actually decided to trust, not from anywhere an attacker can construct a URL for.

What If You Genuinely Need Broad, User-Controlled Image Sources

For a case like user-generated content where images could legitimately come from many different, unpredictable domains, a wildcard isn't the only option, and it's worth resisting it even here. A more careful approach validates and stores the actual final image URL at upload time, ideally re-hosting the image on your own trusted storage rather than proxying an arbitrary external URL live on every request, which removes the SSRF surface entirely rather than trying to sanitize URLs on the fly, a genuinely hard problem to get completely right.

The Broader Rule

Any server-side mechanism that fetches a URL based on client-supplied input is a potential SSRF vector, and next/image's remotePatterns wildcard is a specific, easy-to-overlook instance of a much more general pattern. The same caution applies to any custom endpoint you build that fetches a URL, downloads a file, or proxies a request based on something a client sent, not just this one specific Next.js feature.

Check Your Own Config

grep -A 5 "remotePatterns" next.config.ts

If you see hostname: '**' or a similarly broad wildcard, and your app has any internal services or cloud infrastructure reachable from where it runs, this is worth tightening today, not eventually. Replace it with an explicit list of the actual domains your images genuinely come from.

If you're running a wildcard remotePatterns config right now, genuinely curious what led to it, deliberate convenience tradeoff, or just copied from a tutorial without thinking through what it actually opens up. Drop your situation in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

DEV Community