SSR Bundle exposes original assets from prerendered pages to `_astro`

[spaceemotion]

Astro Info

Astro                    v5.17.2
Vite                     v6.4.1
Node                     v24.13.0
System                   Linux (x64)
Package Manager          pnpm
Output                   static
Adapter                  @astrojs/vercel (v9.0.4)
Integrations             none

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

No response

Describe the Bug

When added a route that's either being prerendered on the server, or just does a simple REST API response, the SSR build mode gets enabled. However, this immediately pulls seems to pull in all the assets in the module graph, even for assets that are only used on pages that are statically prerendered.

This causes the final deployment output to balloon, especially on larger sites, and even more so when using large original PNG files (e.g. over 1MB each).

This also exposes all Astro sites that do have SSR enabled to the ability to "guess" the original file name from any Image emitted by the build process:

For example, using the official Astro page:

1. https://astro.build/_astro/starlight-lp.Cy5G1hqN_ZFOB5U.webp?dpl=698f012b5f244e000861f795 is a screenshot of a website in WEBP
2. if I remove the extra suffix + change webp to png: https://astro.build/_astro/starlight-lp.Cy5G1hqN.png?dpl=698f012b5f244e000861f795
3. The original file shows up

What's the expected result?

• Only the assets required for pages marked as export prerendered = false should be pulled into the final output.
• None of the original images should show up in the client build output, and only should be accessible to the server build (where it may need them to render the page server-side).

Link to Minimal Reproducible Example

https://github.com/spaceemotion/astro-bug-original-file-exposure-ssr

Participation

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

[astrobot-houston]

I was able to reproduce this issue. In server mode builds (triggered by any adapter), original unoptimized source images are copied to dist/client/_astro/ alongside their optimized versions, making them publicly accessible via a predictable URL pattern.

Fix: I was able to fix this issue. The fix filters out optimized original images in ssrMoveAssets() before they are moved to the client directory, ensuring only the optimized versions are publicly served. All existing image-related tests pass with no regressions. View Fix

Cause: In server mode builds, generateImagesForPath() skips deleting original source images (because env.isSSR is true), and then ssrMoveAssets() indiscriminately moves all prerender assets — including the surviving originals — to the client-facing dist/client/_astro/ directory.

Impact: All Astro sites using any SSR adapter (even with mostly prerendered pages) expose original unoptimized source images publicly, causing bloated deployment output and a security concern where original assets can be accessed by guessing the filename pattern from the optimized image URL.

Full Triage Report

Reproduction Report: Issue #15503

Issue Title

SSR Bundle exposes original assets from prerendered pages to _astro

Issue Description

When a site uses an SSR adapter (even if most pages are statically prerendered), original source images are copied to the client _astro output directory alongside their optimized versions. This has two consequences:

1. Bloated deployment output: Original unoptimized images (often large PNGs/JPGs) are included in the client-facing _astro directory unnecessarily.
2. Security concern: Original source images are accessible by anyone who can guess the filename pattern. For example, if the optimized image is test-image.DkdWcrCY_zybrp.webp, the original is available at test-image.DkdWcrCY.png.

The reporter demonstrated this on astro.build itself:

• Optimized: https://astro.build/_astro/starlight-lp.Cy5G1hqN_ZFOB5U.webp
• Original exposed: https://astro.build/_astro/starlight-lp.Cy5G1hqN.png (accessible by changing extension and removing suffix)

Environment

• Astro: workspace (latest from monorepo, equivalent to latest v5/v6 beta)
• Node.js: v24.13.0
• Adapter: @astrojs/node (standalone mode) — used instead of @astrojs/vercel from the original report, since the bug is in the core build pipeline, not adapter-specific
• Package Manager: pnpm
• Output mode: static (with adapter, making it "server" mode internally)

Reproduction Status: REPRODUCED

Reproduction Steps

Setup

1. Created an Astro project with @astrojs/node adapter (standalone mode)
2. Created a simple page (src/pages/index.astro) that uses <Image> component to render a PNG as optimized webp
3. Created an SSR API route (src/pages/api/hello.ts) with export const prerender = false
4. Added a test PNG image (src/assets/test-image.png, 310 bytes)

astro.config.mjs

import { defineConfig } from 'astro/config';
import node from '@astrojs/node';

export default defineConfig({
  output: 'static',
  adapter: node({ mode: 'standalone' }),
});

src/pages/index.astro

---
import { Image } from 'astro:assets';
import TestImage from '../assets/test-image.png';
---
<html lang="en">
<body>
  <Image src={TestImage} width={100} height={100} format="webp" alt="test" />
</body>
</html>

src/pages/api/hello.ts

import type { APIRoute } from "astro";
export const prerender = false;
export const POST: APIRoute = async () => {
  return new Response(JSON.stringify({ message: "Hello, World!" }));
};

Test Procedure

1. Build with adapter (SSR mode): pnpm build

   • Result: dist/client/_astro/ contains BOTH:
     • test-image.DkdWcrCY_zybrp.webp (optimized, 110 bytes) -- expected
     • test-image.DkdWcrCY.png (original, 310 bytes) -- BUG: should NOT be here

2. Build without adapter (pure static mode): Removed adapter from config, rebuilt

   • Result: dist/_astro/ contains ONLY:
     • test-image.DkdWcrCY_zybrp.webp (optimized, 110 bytes) -- correct!
   • The original PNG is NOT present in the output -- this is the expected behavior

3. Server accessibility test: Started the Node.js server and made HTTP requests

   • GET /_astro/test-image.DkdWcrCY_zybrp.webp → HTTP 200 (110 bytes) -- expected
   • GET /_astro/test-image.DkdWcrCY.png → HTTP 200 (310 bytes) -- BUG: original accessible
   • The HTML page only references the .webp version, yet the original .png is served

4. Baseline verification: Even removing the SSR API route (keeping only the adapter), the original PNG still appears in dist/client/_astro/. The presence of an adapter alone triggers "server" build mode, which causes this behavior.

Key Observations

1. The bug is in the build pipeline, not adapter-specific: It manifests with any adapter (@astrojs/node, @astrojs/vercel, etc.) because the issue is in how the core Astro build handles assets in "server" mode vs "static" mode.

2. Build mode is the trigger: When the build log shows mode: "server" (which happens whenever an adapter is configured), original images are copied to the client output. When mode: "static", only optimized images are emitted.

3. The image hash is predictable: The original file's hash (DkdWcrCY) is embedded in the optimized filename (test-image.DkdWcrCY_zybrp.webp). Anyone can derive the original filename by extracting the hash portion and appending the original extension.

4. Root cause theory: In server mode, Vite's asset handling likely copies the original imported image to the client output as a fallback or because the server build references it. The "Rearranging server assets" step in the build may not properly filter out original images that have already been optimized and are only needed for the build-time optimization step.

5. Files to investigate for root cause:

   • packages/astro/src/assets/build/generate.ts - Image generation during build
   • packages/astro/src/core/build/ - Build pipeline, particularly how assets are copied between server and client output
   • The "Rearranging server assets" step in the build pipeline
   • Vite's asset handling configuration in server mode vs static mode

Expected Behavior

• Only optimized/transformed images should appear in _astro client output
• Original source images should NOT be accessible via the web server
• The build output size should not include unnecessary original assets

Actual Behavior

• Original source images (PNG, JPG, etc.) are copied to dist/client/_astro/ alongside their optimized versions
• These original files are publicly accessible via HTTP
• The filename pattern is predictable, making it easy to discover original assets

---

Diagnosis

Confidence: high

Root Cause

The bug is caused by a combination of two behaviors in the server-mode build pipeline that together result in original (unoptimized) source images being placed in the client-facing _astro directory:

1. Image deletion is disabled for SSR builds (packages/astro/src/assets/build/generate.ts:113-131)

In generateImagesForPath(), after an image is optimized, the original file is conditionally deleted:

// Line 113-131
if (
    !env.isSSR &&  // <-- Always false in server builds
    transformsAndPath.originalSrcPath &&
    !globalThis.astroAsset.referencedImages?.has(transformsAndPath.originalSrcPath)
) {
    await fs.promises.unlink(getFullImagePath(originalFilePath, env));
}

When env.isSSR is true (which it is for ALL server builds, including those where the image is only used on prerendered pages), the original image is never deleted. The comment explains: "In SSR, we cannot know if an image is referenced in a server-rendered page, so we can't delete anything."

This is too conservative for images only used on prerendered pages, which are fully rendered at build time and don't need the original at runtime.

2. ssrMoveAssets indiscriminately moves ALL tracked assets to client directory (packages/astro/src/core/build/static-build.ts:530-577)

After generatePages() completes, ssrMoveAssets() moves ALL assets tracked via emitClientAsset() from the prerender directory to dist/client/. This includes the original source images that were not deleted:

// Line 542-554
const prerenderAssetsToMove = getSSRAssets(internals, ASTRO_VITE_ENVIRONMENT_NAMES.prerender);
// Moves ALL files including originals: ['_astro/test-image.DkdWcrCY.png']

3. Build order difference between static and server modes (packages/astro/src/core/build/static-build.ts:197-215)

• Static mode (line 198-206): ssrMoveAssets() → generatePages() → cleanup. Assets are moved FIRST, then optimization generates the optimized image and deletes the original (because env.isSSR is false).
• Server mode (line 207-215): generatePages() → ssrMoveAssets() → cleanup. Optimization runs but does NOT delete the original (because env.isSSR is true), then ssrMoveAssets() copies the surviving original to client output.

4. referencedImages tracking is disabled in server builds (packages/astro/src/assets/utils/proxy.ts:14-18)

The proxy code that tracks whether an image is "directly referenced" (e.g., <img src={img.src}> vs <Image src={img}>) is disabled when isSSR is true:

${!isSSR
    ? `if (target[name] !== undefined && globalThis.astroAsset) globalThis.astroAsset?.referencedImages.add(${stringifiedFSPath});`
    : ''  // SSR: no tracking
}

And this flag is set based on settings.buildOutput === 'server' (line 309 of vite-plugin-assets.ts), NOT the specific environment. So even prerendered pages in a server build don't track referencedImages.

Instrumentation Results

Debug logging confirmed the exact flow:

[DEBUG generateImagesForPath] originalFilePath: /_astro/test-image.DkdWcrCY.png
[DEBUG generateImagesForPath] env.isSSR: true
[DEBUG generateImagesForPath] originalSrcPath: /home/runner/work/astro/astro/triage/issue-15503/src/assets/test-image.png
[DEBUG generateImagesForPath] referencedImages: []
[DEBUG generateImagesForPath] would delete? false
[DEBUG ssrMoveAssets] prerender assets to move: [ '_astro/test-image.DkdWcrCY.png' ]

1. The image optimization generates the optimized webp correctly
2. Deletion check: env.isSSR is true → skip deletion → original PNG survives
3. ssrMoveAssets sees _astro/test-image.DkdWcrCY.png in its prerender assets list
4. Original PNG gets moved to dist/client/_astro/test-image.DkdWcrCY.png
5. The server output (dist/server/) has ZERO references to this image — confirming it's not needed at runtime

Affected Files

File	Lines	Role
packages/astro/src/assets/build/generate.ts	113-131	Deletion logic skipped for SSR
packages/astro/src/core/build/static-build.ts	207-215	Server mode build order
packages/astro/src/core/build/static-build.ts	530-577	ssrMoveAssets() — no filtering of optimized originals
packages/astro/src/core/build/vite-plugin-ssr-assets.ts	47-62	Tracks ALL emitted assets indiscriminately
packages/astro/src/assets/utils/proxy.ts	14-18	referencedImages tracking disabled in SSR
packages/astro/src/assets/vite-plugin-assets.ts	306-311	isSSR flag based on buildOutput not environment

Suggested Fix Approach

The most targeted and safest fix would be to filter out optimized original images in ssrMoveAssets() before moving them to the client directory. After generatePages() completes, globalThis.astroAsset.staticImages contains a map of all original image paths that were optimized. These originals should NOT be moved to the client directory unless they are also directly referenced.

---

Fix

Fix Status: SUCCESSFUL

What Was Changed

Modified packages/astro/src/core/build/static-build.ts — the ssrMoveAssets() function.

The Problem: In server mode builds, after generatePages() runs, original source images survive in the prerender output directory because generateImagesForPath() skips deletion when env.isSSR is true. Then ssrMoveAssets() indiscriminately moves ALL prerender assets to the client directory, including these surviving original images, exposing them publicly.

The Fix: Before moving prerender assets to the client directory, we now build a set of "optimized originals" — original source images that have been optimized via the image pipeline and are not directly referenced. These are identified by iterating globalThis.astroAsset.staticImages (populated during generatePages()). Any prerender asset matching an optimized original is skipped during the move step.

This approach is minimally invasive:

• Only affects the asset move step, not the image optimization pipeline
• Only applies in server mode builds (not static builds)
• Preserves images that ARE directly referenced (checked via globalThis.astroAsset.referencedImages)
• Preserves SSR environment assets (which may be needed at runtime)
• Does not change the build order or deletion logic in generateImagesForPath

Git Diff

diff --git a/packages/astro/src/core/build/static-build.ts b/packages/astro/src/core/build/static-build.ts
index 19e604f..d79e5fb 100644
--- a/packages/astro/src/core/build/static-build.ts
+++ b/packages/astro/src/core/build/static-build.ts
@@ -32,6 +32,8 @@ import { NOOP_MODULE_ID } from './plugins/plugin-noop.js';
 import { ASTRO_VITE_ENVIRONMENT_NAMES } from '../constants.js';
 import type { InputOption } from 'rollup';
 import { getSSRAssets } from './internal.js';
+import { getStaticImageList } from '../../assets/build/generate.js';
+import { removeLeadingForwardSlash } from '../path.js';
 
 const PRERENDER_ENTRY_FILENAME_PREFIX = 'prerender-entry';
 
@@ -539,11 +541,32 @@ async function ssrMoveAssets(
 		? opts.settings.config.outDir
 		: opts.settings.config.build.client;
 
+	// Build a set of original image paths that have been optimized and don't need to be
+	// moved to the client directory. In SSR builds, original source images survive because
+	// the deletion logic in generateImagesForPath is skipped (env.isSSR is true).
+	// We filter them out here to prevent exposing original unoptimized images publicly.
+	const optimizedOriginals = new Set<string>();
+	if (!isFullyStaticSite) {
+		const staticImages = getStaticImageList();
+		for (const [originalPath, data] of staticImages) {
+			if (
+				data.originalSrcPath &&
+				!globalThis.astroAsset?.referencedImages?.has(data.originalSrcPath)
+			) {
+				// staticImages keys have a leading slash (e.g. "/_astro/test-image.DkdWcrCY.png")
+				// but prerenderAssetsToMove entries don't (e.g. "_astro/test-image.DkdWcrCY.png")
+				optimizedOriginals.add(removeLeadingForwardSlash(originalPath));
+			}
+		}
+	}
+
 	// Move prerender assets
 	const prerenderAssetsToMove = getSSRAssets(internals, ASTRO_VITE_ENVIRONMENT_NAMES.prerender);
 	if (prerenderAssetsToMove.size > 0) {
 		await Promise.all(
 			Array.from(prerenderAssetsToMove).map(async function moveAsset(filename) {
+				// Skip original images that have been optimized - they should not be served publicly
+				if (optimizedOriginals.has(filename)) return;
 				const currentUrl = new URL(filename, appendForwardSlash(prerenderOutputDir.toString()));
 				const clientUrl = new URL(filename, appendForwardSlash(clientRoot.toString()));
 				if (!fs.existsSync(currentUrl)) return;

Verification Results

1. Reproduction project rebuild: After the fix, dist/client/_astro/ contains ONLY the optimized test-image.DkdWcrCY_zybrp.webp (110 bytes). The original test-image.DkdWcrCY.png is no longer present.

2. Server accessibility test:

   • GET /_astro/test-image.DkdWcrCY_zybrp.webp → HTTP 200 (110 bytes) — correctly served
   • GET /_astro/test-image.DkdWcrCY.png → HTTP 404 — correctly NOT accessible

3. Test suite results (all passing, no regressions):

   • test/core-image.test.js: 100 tests passed
   • test/core-image-picture-emit-file.test.js: 6 tests passed
   • test/astro-assets.test.js: 5 tests passed
   • test/build-assets.test.js: 14 tests passed (both static and server modes)
   • test/css-assets.test.js: 2 tests passed

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

[0xRozier]

I would like to work on this issue, I'll try to submit a PR tomorrow unless it bothers someone.