Doesn't throw error if domain isn't in image domains list using Cloudflare adapter

[LouieRichardson99]

Astro Info

Astro                    v6.1.2
Vite                     v7.3.1
Node                     v23.11.0
System                   macOS (arm64)
Package Manager          npm
Output                   static
Adapter                  @astrojs/cloudflare (v13.1.3)

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

There is no error being thrown during development when trying to load a remote image that isn't listed as a domain in our image domains config - I'm using the Cloudflare adapter.

What's the expected result?

It should throw an error like it usually would on a fresh project.

Link to Minimal Reproducible Example

Can't use Cloudflare adapter in Stackblitz

Participation

• I am willing to submit a pull request for this issue.

[astrobot-houston]

I was able to reproduce this issue. When using the <Image> component with a remote image whose domain is not listed in image.domains, no error or warning is thrown during development. However, this is not specific to the Cloudflare adapter — the same silent passthrough behavior occurs with all image services, including the default sharp service. The root cause is in baseService.getURL() (packages/astro/src/assets/services/service.ts:363-365), which silently returns the original remote URL when the domain is not in the allowlist, instead of throwing an error or logging a warning. The image simply renders with the original URL, bypassing the optimization endpoint entirely.

I was unable to find a fix for this issue. A fix would involve adding either an error or a warning in baseService.getURL() (or in getImage() in packages/astro/src/assets/internal.ts) when a remote image source is not in the configured image.domains or image.remotePatterns. Currently, the only validation that throws an error is when inferSize: true is used (internal.ts:87-91). The endpoint-level 403 checks in generic.ts and shared.ts exist but are never reached because getURL() short-circuits before the image is routed to the optimization endpoint. A potential fix location would be around line 193 of internal.ts, after service.getURL() returns, to check if the returned URL is the same as the original remote source and emit a warning.

P2: nice to have. The current behavior silently degrades — remote images from non-allowed domains still render correctly in the browser (fetched directly from the remote server), they just aren't optimized. This affects any user who expects domain validation to produce a visible error, but the images still work. This is not a build-breaking or functionality-breaking issue, and it applies to all adapters equally, not just Cloudflare.

Full Triage Report

Reproduction

The issue reports that using the Cloudflare adapter, no error is thrown during development when loading a remote image whose domain isn't in the image.domains config. A minimal reproduction could not be provided by the reporter due to Cloudflare adapter limitations in StackBlitz.

Root Cause Analysis

The behavior is not specific to the Cloudflare adapter. It affects all image services (sharp, noop, cloudflare-workerd, cloudflare-external) because they all use or inherit baseService.getURL().

The silent passthrough in baseService.getURL()

File: packages/astro/src/assets/services/service.ts, lines 356-366

getURL(options, imageConfig) {
    const searchParams = new URLSearchParams();
    if (isESMImportedImage(options.src)) {
        searchParams.append('href', options.src.src);
    } else if (isRemoteAllowed(options.src, imageConfig)) {
        searchParams.append('href', options.src);
    } else {
        // If it's not an imported image, nor is it allowed using the current domains
        // or remote patterns, we'll just return the original URL
        return options.src;
    }
    // ...
}

When a remote image's domain is not in the allowlist, getURL() silently returns the original URL. No error, no warning.

Where errors ARE thrown (but only for inferSize)

File: packages/astro/src/assets/internal.ts, lines 86-92

if (isRemoteImage(resolvedOptions.src) && isRemotePath(resolvedOptions.src)) {
    if (!isRemoteAllowed(resolvedOptions.src, imageConfig)) {
        throw new AstroError({
            ...AstroErrorData.RemoteImageNotAllowed,
            message: AstroErrorData.RemoteImageNotAllowed.message(resolvedOptions.src),
        });
    }
}

This only fires when inferSize: true. Regular <Image src="https://unlisted-domain.com/img.png" /> usage never hits this path.

Endpoint-level checks exist but are unreachable

Both packages/astro/src/assets/endpoint/generic.ts:54 and packages/astro/src/assets/endpoint/shared.ts:50 check isRemoteAllowed and return HTTP 403, but these checks are never reached because getURL() already returned the original URL, so the request is never routed through the optimization endpoint.

All services affected equally

• sharp (packages/astro/src/assets/services/sharp.ts:137): Uses baseService.getURL directly
• noop (packages/astro/src/assets/services/noop.ts:6): Spreads ...baseService, inherits getURL
• cloudflare-workerd (packages/integrations/cloudflare/src/entrypoints/image-service-workerd.ts): Spreads ...baseService, inherits getURL
• cloudflare-external (packages/integrations/cloudflare/src/entrypoints/image-service-external.ts): Has its own getURL with the same silent-return behavior

Cloudflare dev mode specifics

When using imageService: 'cloudflare', the Cloudflare adapter switches to the noop/passthrough service in dev mode (packages/integrations/cloudflare/src/utils/image-config.ts:71-76), which inherits the same baseService.getURL() behavior. This means in dev, cloudflare mode provides no image optimization AND no domain validation errors.

Suggested Fix Direction

Add a warning (or error, depending on desired strictness) when getImage() detects that service.getURL() returned the original remote URL unchanged — indicating the domain was not in the allowlist. This could be added around line 193 of packages/astro/src/assets/internal.ts.

This report was made by an LLM. Mistakes happen, check important info.