Angular assets folder exposes internal files as public URLs — choosing what belongs in the build output

Question

I'm designing an Angular workspace (current CLI, standalone app) and need to settle how static files are published. My understanding is that anything listed under the assets array in angular.json is copied verbatim into the output directory and served at a predictable public URL, with no framework-level access control. That makes it easy to accidentally ship internal documentation, mock data, or configuration files simply because they lived in a convenient folder.

The unresolved decision is where to draw the line: route guards protect navigation but not direct asset URLs, and TypeScript visibility modifiers don't apply to files at all. So the only real control seems to be what gets copied into dist in the first place, plus server-side rules outside Angular's scope.

Before committing to a convention, I want to confirm the boundaries:

Is there any supported Angular mechanism to mark individual asset paths as non-public or excluded per build configuration, or is exclusion from the assets array the only option?
For files that must ship but shouldn't be guessable (e.g., fetched only after login), is the intended pattern to keep them out of the bundle entirely and serve them from a protected backend endpoint?
Does the default public path behavior differ enough across recent CLI major versions that I should pin assumptions in documentation?

Tasadduq Burney · Answer

Answer
The Angular CLI has no built‑in mechanism to mark individual asset entries as non‑public. The only way to keep a file from being served via a predictable /assets/ URL is to exclude it from the assets array in angular.json (or move it outside the configured asset folders).
Confirmed facts

The CLI copies exactly the paths/globs listed in the assets array into dist//assets during ng build or ng serve. No per‑file flag or attribute exists to hide a subset.
  Files that must be shipped but should not be guessable (e.g., data fetched only after login) are best kept out of the assets array entirely and served from a protected backend endpoint that enforces authentication/authorization.
  The default public path for assets (/assets/) and the copying behavior have been stable from Angular CLI v12 through v17; no version‑specific pinning is required for this behavior.

Steps to verify your setup

Open angular.json and confirm which folders/globs appear in the assets array.
  Run ng build --configuration production (or ng serve) and inspect dist//assets to see which files were copied.
  Attempt to request a file you omitted from the array via its expected URL (e.g., https://example.com/assets/internal/config.json). It should return 404, confirming exclusion.

Missing diagnostic detail
If you are using a custom Angular builder or a third‑party schema that modifies the asset pipeline, the default behavior described above may not apply. Please confirm whether your project employs any custom builder or asset‑transforming schematic; if yes, you’ll need to verify its specific configuration.

Angular assets folder exposes internal files as public URLs — choosing what belongs in the build output

1 answer

Answer

Confirmed facts

Steps to verify your setup

Missing diagnostic detail

Your perspective belongs here.

0 question comments