Anything the browser app can read is public, so secrets belong on a server. Angular environment files are imported by app code, and Nuxt's public runtime config is added to every page payload. Only Nuxt's private runtime config keys stay on the server.
The rule that decides everything
A front-end bundle is downloaded and run by the people you least want reading your keys. If a value is compiled into the JavaScript, or sent in the page payload, treat it as published. The question is never "is the file hidden in the repo", it is "does the browser receive it".
Angular: environment files
Angular's build environments let you define named configurations. The documentation shows application code importing an environment object and reading a field such as an API URL from it, with angular.json using fileReplacements to swap the file for each target. Because that code is part of the app the browser runs, the values are part of the bundle. Use the environment file for things like the public address of your API, and never for a private API key, signing secret or database credential.
Nuxt: private versus public runtime config
Nuxt's documentation separates two kinds of keys. Keys in the main runtimeConfig object are private and only available on the server. Keys inside the public object are exposed to client side code, and the docs say Nuxt adds them to each page payload. The same docs note a few helpful rules:
- Custom runtime config variables must be declared in nuxt.config, so arbitrary environment variables are not exposed to application code.
- Only an uppercase variable starting with NUXT_ can override a runtime config value.
- The .env file is read in development, build and generate, but not when you run the built server, so production values must come from the real environment.
Quick reference
| Where the value lives | Visible to a visitor? | Good for |
|---|---|---|
| Angular environment file | Yes, it is compiled into the app | Public API base URL, feature flags |
| Nuxt runtimeConfig.public | Yes, in the page payload | Public base paths, public keys meant for browsers |
| Nuxt private runtimeConfig | No, server only | Server side API keys, session secrets |
| Browser storage | Yes, to any script on the page | Preferences only |
How to check your own build
- Build the production bundle and search the output files for a few strings: your API key prefix, "secret", "password", and names of third party services.
- In Nuxt, open a rendered page, view the page source and read the data payload for anything that should be private.
- Review every public config key and ask whether you would be comfortable printing it on a billboard.
- If a key was ever placed in a public setting, rotate it, since it may have been cached or logged.
- Add a secret scanner to your commits and to CI, so a mistake is caught before release.
When the front end needs a protected call
Put a small server endpoint in front of the third party service. The browser calls your endpoint, which holds the key and applies limits per user. This also gives you one place to log and revoke.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings name the file and line, which is how a hardcoded key review should read.
Safeguard's free scan at gold.safeguard.sh/scan covers dependency risk in front-end projects.
Quick check
Is an Angular environment file private because it is not in the page HTML?
No. It is imported by application code, so its values end up in the JavaScript the browser downloads.
Can I put a key in Nuxt public config if it is only used by my own pages?
Public config is sent to every visitor. If the key must stay secret, keep it in private runtime config and call it from server code.
Sources
Last reviewed: 19 October 2026.
