-
-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Server variable names and schemas are exposed to the client #30
Comments
Personally, I don't think it's really an issue that we need to worry about, as long as the actual value is strip out. I don't think leaking the env name will actually tell much about your system, I mean I can pretty guess what sort of envs you have in your system without even have to look at the env names that you have. But I do understand your concern there |
I don't think it is possible to tree-shake the server envs, not that I know of. But it doesn't stop you from creating separate env with 'createEnv' for both server and client, then put them to place that you want and let the bundler tree-shake it for you🙂 |
If you're concerned that the schema is leaked this is probably the way - however we had separeate server/client envtrypoints and the dx was quite a bit worse... |
I think there is an important security concern here because environment variables often hold API keys for named or easily guessable third-party services. If one of those services is compromised I'd rather there not be easily scriptable tools announcing that my backend uses them and might be vulnerable. |
It's kind of concerning that DX is being prioritized over ensuring that the library and its consumers' usages are inherently secure. Anyone who uses the |
As it's currently implemented, both server and client code refer to the same instance of t3-env (the output of
createEnv()
)This means that using T3-env leaks the following information about your server-side environment variables in your client-side code:
While this is nowhere near as bad as the values themselves being leaked, I think that is still some cause for concern.
I think there is at least some potential for consumers of this library to unknowingly leak secret sever-side implementation details, not realizing that server variable names and zod schemas will be visible in their client code.
I wonder if there's a way to split up the client and server envs so that the server code can be tree-shaken out of the client bundle? If it's even possible, it would probably be a drastic change to the API though.
If the API cannot be changed to avoid leaking server info to the client, it would probably make sense to add a note in the documentation warning users that this information will end up in their client JS.
The text was updated successfully, but these errors were encountered: