Allow a wildcard for images.domains in next.config.js / ability to disable Next/Image hostname check

[petertenhoor]

Feature request

A. The ability to use a wildcard or regular expression in the images.domains array within the next.config.js.
B. The ability to disable the hostname check when using Next/Image.

Is your feature request related to a problem? Please describe.

I'm trying to implement Next/Image in my current project with externally hosted images. My images are hosted on an external server which regularly changes hostnames to a random subdomain (e.g. s1-abc-def.domain.com). This makes it nearly impossible for me to use Next/Image with the current way hostnames are validated.

Describe the solution you'd like

A. It looks like the Next/Image component uses Array.includes to match the hostname of an image with the configured domains array in the next.config.js. It would be great if the ability to use a wildcard (e.g. *.domain.com) or regex could be added.
B. A new parameter in the next.config.js which allows you to disable the domains check for images.

Describe alternatives you've considered

• Not using Next/Image.
• Set up an extra image proxy and whitelist that as a domain.

Additional context

N/A

[klaaz0r]

I like the idea but I red in the PR the worries about Ddosing which of course is a real issue if you allow any domain.

[jerrygreen]

I don't quite understand: how ddosing would be achieved by having all domains allowed in next.config.js?

UPD. Actually, I got this one by figuring out how that works. I might be wrong but it seems nextjs setups an url /_next/image which is kinda "built-in API function", which accepts an attribute url, i.e. /_next/image?url=..., and it generates an optimized image based on that, so if people will allow any domain, it will be possible to abuse url attribute, ask it to access some 10000x10000px images, and make the service generate a lot of images based on that, consuming app limits & eating out budgets.

I think that might be solved by some kind static: true setting, so this built-in api function will generate previews only during next build stage, and after this step it will only act as cache, not generating new ones. That would be handy for static-first apps, like documentation, markdown blogs, etc.

[Richmond-Eribo]

I don't quite understand: how ddosing would be achieved by having all domains allowed in next.config.js?

UPD. Actually, I got this one by figuring out how that works. I might be wrong but it seems nextjs setups an url /_next/image which is kinda "built-in API function", which accepts an attribute url, i.e. /_next/image?url=..., and it generates an optimized image based on that, so if people will allow any domain, it will be possible to abuse url attribute, ask it to access some 10000x10000px images, and make the service generate a lot of images based on that, consuming app limits & eating out budgets.

I think that might be solved by some kind static: true setting, so this built-in api function will generate previews only during next build stage, and after this step it will only act as cache, not generating new ones. That would be handy for static-first apps, like documentation, markdown blogs, etc.

Hey, concerning this nextjs setup, using the built in API function. I am unable to fetch my image url because it is giving me a 400 bad request response.

[M1ck0]

To enable Image Optimization for images hosted on an external website, use an absolute URL for the Image src and specify which domains are allowed to be optimized. This is needed to ensure that external URLs can't be abused.

This is from docs. I do like the reason behind this because it can easily be abused in many ways which would not benefit anyone, especially to the NextJS team.

[wittycodes]

In production or otherwise, if the media or static-assets CDN dynamically generates subdomains based upon different optimized versions/revisions of images. We may not predetermine the absolute hostname and, would like to end up using wildcard anyhow. Or as suggested earlier having an application loadbalancer may help but costly for purpose.

For instance etsy: https://img1.etsystatic.com/000/0/5187652/il_570xN.326921479.jpg

Yes, also having wildcard, may invite security concerns when external URLs are abused.

=> Wildcards can't be allowed for primary domains (TLDs) but, would be worth considering for subdomains or further levels down in domain's hierarchy

[harrylaou]

In production or otherwise, if the media or static-assets CDN dynamically generates subdomains based upon different optimized versions/revisions of images. We may not predetermine the absolute hostname and, would like to end up using wildcard anyhow. Or as suggested earlier having an application loadbalancer may help but costly for purpose.

For instance etsy: https://img1.etsystatic.com/000/0/5187652/il_570xN.326921479.jpg

Yes, also having wildcard, may invite security concerns when external URLs are abused.

=> Wildcards can't be allowed for primary domains (TLDs) but, would be worth considering for subdomains or further levels down in domain's hierarchy

+1 for this. I can only guess that wildcard in subdomain is needed.

[pronevich]

Was the issue opened? Many providers have a dynamic subdomain, also social networks images requested by API

[zacharypodbela]

Agreed with @pronevich. Facebook for example has several subdomains all of which on the fbcdn.net domain. Examples I've seen in the last 5 minutes alone: scontent.xx.fbcdn.net, scontent-atl3-1.xx.fbcdn.net. Without the ability to wildcard the subdomain it renders the Image component effectively useless.

[jacobtoye]

A hacky work around I've temporarily implemented is to allow one images domain in next.config.js and replace any subdomains with this allowed subdomain.

I..e for Instagram

media_url.replace(/^[^.]*/, 'https://scontent-akl1-1'),

[hardliner-home]

@jacobtoye

Could you show full example?

[jacobtoye]

Sure, my next.config.js looks like:

module.exports = {
  reactStrictMode: true,
  images: {
    domains: ['scontent-akl1-1.cdninstagram.com'],
  },
};

The option you want is the images.domains one. See the official docs: https://nextjs.org/docs/basic-features/image-optimization#domains

[stoickeyboard]

A hacky work around I've temporarily implemented is to allow one images domain in next.config.js and replace any subdomains with this allowed subdomain.

I..e for Instagram

media_url.replace(/^[^.]*/, 'https://scontent-akl1-1'),

how does the image work after you've modified it's domain?

[jacobtoye]

how does the image work after you've modified it's domain?

You are just changing it to a specific Instagram/Facebook (or whatever else) domain. So choose the one you want from all the possible Instagram/Facebook CDN's. The issue this is trying to resolve is making it so it matches whatever you have in your next.config.js

[syntichsizer]

Do we have any updates on this issue? I'm using cloudfront which changes subdomains pretty often, thus making Image unusable to me :(

[FDiskas]

This could work #27345

[Dradows]

Can it work now? It would be greatly helpful.

[FDiskas]

Pr is ready for review. But it's more like idea rather than real pull request. I don't know internal vision of nextjs

[bmstefanski]

Hi, I was also battling with this and managed to make a workaround to this issue by creating an image proxy. It is open-sourced & on npm, you can check the source here https://github.com/Blazity/next-image-proxy

// pages/api/imageProxy.ts

import { withImageProxy } from '@blazity/next-image-proxy'

export default withImageProxy({ whitelistedPatterns: [/^https?:\/\/(.*).medium.com/] })

import NextImage from 'next/image'

export function SomeComponent() {
  const actualImageUrl = 'https://cdn-images-1.medium.com/max/1024/1*xYoAR2XRmoCmC9SONuTb-Q.png'

  return <NextImage src={`/api/imageProxy?imageUrl=${actualImageUrl}`} width={700} height={300} />
}

[jerrygreen]

The problem comes that image is like a separate api request, with url parameters. With this approach, it would be security hole if we allow wildcard domains.

The image component is fundamentally made wrong. It shouldn’t be an api request to a hidden _next url, it should be a build step logic for initial deploy, like getStaticProps, - and getServerSideProps for dynamic pages. Hence, it should be something more like a middleware, rather than a component. In this case, there’s fundamentally no need to setup domain list, no hole in the first place.

[moggiex]

The issue here is that right now rather than allowing wildcards for trusted domains (remember the developer is manually adding these), the developer is now not setting any value at all for allowed domains.

So one huge security hole is being left open by not having the ability to wild card sub domains

[jerrygreen]

@moggiex how not allowing any domains is a security hole? You clearly know nothing about security, and you clearly didn’t fully understand my message about that the Image component just fundamentally has wrong approach to how it’s made.

[kdesimini]

Any movement on this? With CDN's a plenty, I can't see why we shouldn't be able to use a wildcard for a subdomain, for example, instagram's cdn.

[chrift]

I see this has been open for 2 years already. I'm surprised that there aren't more replies on this.
I've just come across this thread when trying to use the Image component with a google user profile image (which lives on *.googleusercontent.com

[jerrygreen]

Just don't use Image component, instead a plain img, - Image poorly made and needs a rethought.

[edmondso006]

When using the normal img tag I am getting blocked by cors errors, were as if I use the Image component I am able to view the image. Any help would be appreciated

[lucasbasquerotto]

@edmondso006 If the endpoint in which the img src points to is owned by you, you can allow CORS for the images there (assuming that you access the images in the path your-server.com/assets/img/, and assuming that all images in this base path are public / non-confidential, you can simply allow CORS in this path, returning the CORS headers when an OPTIONS request is done).

[lucasbasquerotto]

@chrift Keep in mind that allowing all subdomains in the googleusercontent.com domain is not safe, because those subdomains could be used by anyone (https://support.google.com/webmasters/thread/145275615/googleusercontent-com-domain?hl=en). It means that anyone can put an unsafe resource there, and CORS would allow that resource to be loaded by your images. It's better to allow your specific subdomains, instead.

[styfle]

This feature is available on the canary channel npm i next@canary using the experimental remotePatterns config.

Update 1: this feature shipped in Next.js 12.2.0

Update 2: this feature is stable in Next.js 12.3.0

[devnobi]

Image is a terrible component. Use img tag instead.

[typeofweb]

Why would you post such a mean and non substantial comment in this thread? If the Image component doesn't meet your need and you want to see it evolve, give meaningful feedback to the authors.

[bmovement]

It might be blunt, but after some initial excitement to do things the "Next way", I'm coming to similar conclusions. It seems that the component is meant be used universally (since I get a build warning telling me to use Image instead of img). The width and height requirement seemed not ideal, but I thought maybe it was "more correct" by some definition. But only being able to display images from an explicit list of domains seems broken.

My advice would be to make the component an improved drop-in replacement for img, or remove the warning.

[typeofweb]

@bmovement The improved drop-in replacement for img was released for testing more than a few weeks ago: https://nextjs.org/docs/api-reference/next/future/image

You can specify a wildcard for dynamic subdomains or paths by using remotePatterns setting: https://nextjs.org/docs/api-reference/next/future/image#remote-patterns

Width and height attributes should always be used even with the native html img element to eliminate Cumulative Layout Shift caused by loading of images. You can read more about this here: https://developer.chrome.com/blog/image-component/

[bmovement]

Good to know… I’ll keep an eye on it for future use. Thanks for the reply!

[tw1t611]

The improvements in next/furture/image are very nice.
However, I have a problem that can't be solved with remote patterns.
https://nextjs.org/blog/next-12-2#remote-patterns-experimental
Building the image at build time would not solve my problem either.

Here is the problem:
I am building a SaaS, where my customers load images of their websites.
The images can be placed at different domains (even per customer).

e.g.
Customer1 logs in and loads images of shop1.com
Customer2 logs in and loads images of s1.shop2.com and shop-cdn.com

Is there a way to load images of different domains, other than going for unoptimized <img />?
A workaround for now, or another next compatible <Image /> component would be fine too.

[styfle]

Does each customer have their own allowlist of image hosts?

You could map the user to domains in Middleware proxy to the upstream image. Then you wouldn't need to configure next.config.js because your config would be the middleware.