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.

[matthewp]

Astrobot, please try again with the latest code.

[astrobot-houston]

• Reproduced: Yes — confirmed on Astro v6.3.3 (latest main). Not specific to Cloudflare; affects all image services.
• Exploration: Yes — View branch
• Unit Test: Yes — packages/astro/test/units/assets/getImage.test.ts (3 new tests + 4 updated)
• Priority: P2: nice to have. The <Image> component silently renders non-allowed remote images without optimization instead of throwing an error. Images still display correctly (fetched directly from the remote server), so nothing is visually broken. This affects any user who expects image.domains to produce a visible error for non-allowed URLs.

The root cause is in getImage() (packages/astro/src/assets/internal.ts): the isRemoteAllowed check that throws RemoteImageNotAllowed only runs when inferSize: true. For regular <Image src="https://unlisted-domain.com/img.jpg" width={300} height={200} /> usage, the code flows directly to baseService.getURL() which silently returns the original URL with no error or warning. This appears to be an incomplete fix from PR #15586 ("Respect remote image allowlists"), which added enforcement for inferSize and endpoints but missed the standard <Image> path.

I found a potential fix for this issue. The fix moves the isRemoteAllowed check to run unconditionally for all remote images in getImage(), before the inferSize block — so non-allowed domains are rejected regardless of whether inferSize is used. The error hint was also updated to remove the now-irrelevant inferSize mention.

Try this fix

You can test this fix right now without waiting for a release:

npm i https://pkg.pr.new/astro@8673a60

If this fixes your issue, please leave a comment letting us know (e.g. "confirmed, this fixes it"). We'll then open a pull request to get this merged.

Full Triage Report

Reproduction

Confirmed on Astro v6.3.3 (latest monorepo source), Node v24.15.0, Linux. Created a minimal project with image.domains: ['example.com'] and two <Image> components — one from a non-allowed domain, one from an allowed domain.

In dev mode: The non-allowed domain image rendered with its original URL (<img src="https://not-allowed-domain.com/test-image.jpg">). No error, no warning. The allowed domain image was correctly routed through /_image?href=....

In build mode: Same silent passthrough — no build error for the non-allowed domain.

Root Cause

The isRemoteAllowed check in getImage() (packages/astro/src/assets/internal.ts) was gated behind if (resolvedOptions.inferSize). For regular <Image> usage with explicit width/height, the code never checks the allowlist — it flows directly to baseService.getURL() (packages/astro/src/assets/services/service.ts:356-366), which silently returns the original URL.

This is an incomplete fix from PR #15586 ("Respect remote image allowlists"), which added the RemoteImageNotAllowed error for inferSize and endpoint-level 403 checks, but missed the standard <Image> code path.

All services using baseService.getURL() are affected equally: sharp, noop, cloudflare-workerd, and cloudflare-external. Netlify and Vercel services are not affected (they always route through their CDN endpoints).

Fix

Added an unconditional isRemoteAllowed check in getImage() that runs for all remote images before any processing:

• packages/astro/src/assets/internal.ts: New check at line 80 throws RemoteImageNotAllowed for non-allowed remote URLs. Removed the duplicate check from inside the inferSize block.
• packages/astro/src/core/errors/errors-data.ts: Updated error hint to 'Update image.domains or image.remotePatterns to allow this image.' (removed inferSize mention).
• packages/astro/test/units/assets/getImage.test.ts: Added 3 new tests for allowlist enforcement; updated 4 existing tests to expect errors instead of silent passthrough.

All 38 unit tests pass, all 6 inferSize integration tests pass, and all 18 remote image integration tests pass.

This report was made by an LLM. The analysis may be wrong, and the potential fix might not work, but is intended as a starting point for exploring the issue.

[matthewp]

Astrobot, this fix looks good to me, please submit a pull request.

[matthewp]

It won't do it unless the submitter says it works, @LouieRichardson99 it's up to you 😄

[matthewp]

I tried this out and can very it is fixed.

[astrobot-houston]

The fix has been verified! A pull request has been created: #16814