search

t3-oss / t3-env

https://env.t3.gg
MIT License
2.65k stars 86 forks source link

Server variable names and schemas are exposed to the client #30

Closed nderscore closed 1 year ago

nderscore commented 1 year ago

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.

chungweileong94 commented 1 year ago

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

chungweileong94 commented 1 year ago

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🙂

juliusmarminge commented 1 year ago

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...

ledburyb commented 1 year ago

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.

nderscore commented 1 year ago

however we had separate server/client entrypoints and the dx was quite a bit worse...

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 create-t3-app template is currently being handed a small footgun with which they can leak server implementation details without any disclaimers or warnings.