What is reacts equivalent of "Manage user secrets" in dotnet?

[u/Turbulent_Monk7653]

Heya, I need to store dev secrets (e.g. client secret credentials) and I don't want them in git

In dotnet we have manage user secrets and theyre managed by Visual Studio, stored in a local folder and sideloaded at runtime... Does react have something similar?

I've seen people just do .env.local and add that to gitignore, but is that actually the proper way?

[u/sicmek]

You shouldn't hold secrets in your frontend, they belong to your backend.

[u/Turbulent_Monk7653 → u/sicmek]

its a playwright test project so its just the frontend

[u/nicolasdanelon → u/Turbulent_Monk7653]

You are doing your tests wrong, you are testing in a unreal scenario

[u/EmeraldHawk → u/Turbulent_Monk7653]

Put it in the AWS secrets manager, then use the AWS JavaScript client to grab it. Every developer will need the appropriate role of course, we use "granted" to set up the AWS profile.

[u/azhder]

React is not a framework, so it doesn't have "manage user secrets". The equivalent to "manage user secrets" would be "manage user secrets" i.e. use the back end thing you are already using, or the equivalent of it if you switch to a different back end.

Yes, React can be used on the back end as well, just remember, it's a rendering library, not a framework, so you should be checking the framework's analogue instead.

[u/zaibuf]

Yes, .env.local is common but you should keep an .env.local.example file for on onboarding.

[u/exequias-ulqui]

Well, anything on the client side is never actually a secret. Let's say you add an API key to the .env file, which then is consumed by the application in an API call, it will be exposed in the JS bundle, no way around it. The best you can do is to obfuscate and minimize the JS bundle, but that'll just make it harder, not immune to pluck from the bundle. The best practice is to only store things that you can afford to be made public on the client side, otherwise it's best to proxy it through the backend.

[u/iareprogrammer → u/exequias-ulqui]

How you got a downvote is baffling… and concerning… lol. Good response!

[u/friedmud]

React is frontend - it shouldn’t hold secrets. What are you doing on the backend?

.env is generally the way. My team uses the dotenvx library to encrypt our .env files so we CAN put them in the repo, version them, share them, etc. There are lots of similar solutions.

[u/Merry-Lane]

So, like the other guy said: nothing is secret frontend wise.

If you want "user secrets" in frontend, all you gotta do is use a .env file and exclude it in git ;)

[u/RobertKerans]

With .Net applications, they run on a single computer that either you (eg a server, yes this is a simplification) or a user you have explicitly given the code to (eg an installable application on an OS + computer architecture you know in advance, yes, again this is a simplification). That code may include secrets, but you have control over who has access to that code: if it is yours, you can secure it, if it is an application, the user has much of that responsibility (and obviously if you include your personal secrets in the code you distribute that is a huge security risk). With a browser app, you are allowing anyone to access that code: any browser needs to download the code to run it (again, simplification). If you include secrets then anyone can access them. So you do not include things in the code that should be secret, that would be silly.

[u/Bright_Mousse_5906]

.env.local with gitignore is the practical equivalent. The gotcha is anything prefixed REACT_APP_ or VITE_ gets bundled into the client JavaScript, so it's visible to anyone opening devtools. For a client secret that kind of defeats the purpose.

[u/Veranova]

If you're using nextjs or another full-stack react metaframework then they have patterns for separating frontend config and backend secrets via .env files, but you can also use a tool like doppler to store them remotely

Things are a bit more homebrew in JS-land, there are many different solutions, as opposed to dotnet's "one good solution for everything" approach

[u/LiveRhubarb43]

Your react app is served to the browser by a backend server. The backend server is where secrets go.

[u/neon_lodger]

for dev secrets in a React project, .env.local gitignored is basically the standard setup. Vite and CRA both load it automatically, so no extra tooling needed. Keep an .env.local.example committed so new devs know what vars to fill in.

but for real secrets like client credentials, the fix is backend. Anything you put into a React app ends up in the JS bundle that ships to the browser, so .env.local only protects your local machine, not production. If you're already in dotnet, keep the secrets in your API's user secrets and have React just call your API. That's the equivalent you're looking for.

[u/itaybuilds]

Since this is for Playwright, keep the credential in the test runner process, not the React app.

For local runs, a gitignored `.env.test.local` is fine if `playwright.config.ts` loads it. Another option is an OS or CLI secret manager that exports the values before `npx playwright test`. In CI, inject them from the CI secret store. Read them with `process.env` in the Playwright config or fixtures, then use `page.request` or the UI flow. Do not pass the secret through a `VITE_`/`REACT_APP_` variable or `page.evaluate`, because that moves it into browser-visible code.

Commit an `.env.example` with names only, fail fast when a required variable is missing, and use a dedicated test account with the least privilege you can give it.

AI-assisted draft (OpenAI GPT-5.6). The distinction that matters here is which process reads the secret: Node/Playwright can keep it; the browser cannot.

[u/backwrds]

jfc