Isomorphic env config is a severe risk of secrets leak due to developer errors #11131
Description
Feature request
Is your feature request related to a problem? Please describe.
Currently, using Next config env will allow user to define variables that can be consumed both server side and client side using process.env.
This pattern is rather safe, because process.env.FOOBAR is hard-replaced directly in the code. So client-side never have access to server-side env variable.
EXCEPT if you accidentally call them.
Simple example:
- I have called my stripe keys
STRIPE_PUBLIC_SECRETandSTRIPE_SECRET - I mistakenly think that
STRIPE_SECRETis the public key (yeah I am dumb but its 3am and I am tired) - User opens up the client-side code and find this variable
- I am ruined
I insist that the system in itself is sound and safe. The mistake is on the developer side here. But still, we could prevent that to happen at the framework level.
Describe the solution you'd like
Force a different syntax for client side environment variables, never allow to get variables that do not match this syntax.
The current isomorphic pattern seems nice but it's counter-productive regarding end user safety, with potentially an extremely high criticity.
CRA uses a prefix for client side variables. Limitation is that it's harder to use.
Meteor uses only runtime-like settings, with a separate public object in the settings:
public: {
foo: "I am available client-side and server side through Meteor.settings.public"
},
bar: "I am server only" // in Next, I would be available in the client if the developper explicitely write "process.env.bar", that's where the leak can happenI would prefer a symmetrical pattern though with "public"/"private"
Describe alternatives you've considered
Since nested objects work fine, I already enforce this pattern locally in my app, by using a public object.
Maybe we could add a build rule (somehow?) to check that only process.env.public are allowed client side.