hoppscotch / hoppscotch

Open source API development ecosystem - https://hoppscotch.io (open-source alternative to Postman, Insomnia)

Home Page:https://hoppscotch.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[bug]: import_meta_env_placeholder exposed differently on different selfhosted deployments

Leon-Luu opened this issue · comments

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

When checking the index.html file on the different selfhosted deployments we can see that import_meta_env_placeholder are being exposed differently. On hoppscotch-aio / hoppscotch-app all the VITE environments are being exposed to the outside world which are not seen the same from the hoppscotch-old-app and the hoppscotch.io. Please check picture below:

On the self-hosed deployment of:
hoppscotch-aio
hoppscotch-app
hoppscotch-sh-admin

image

On the hoppscotch-old-app, hoppscotch-old-sh-admin and the hoppscotch.io the import_meta_env_placeholder are not being replaced by the environment variables.
image

As VITE_PROXYSCOTCH_ACCESS_TOKEN and VITE_ are secrets variables, this could lead to unintended leaks.

Steps to reproduce

  1. docker compose up
  2. check the index.html from the deployments (or open http://localhost:3000 and view page source)
  3. check for globalThis.import_meta_env line

Environment

Production

Version

Self-hosted

@Leon-Luu

None of the variables marked with VITE_ is considered private for the only fact that we need them in the frontend for anything to be done. This is a standard practice in frontend as well. For example, Firebase requires its API keys to be there in the frontend so that it can connect with the firebase services. Basically all analytics platforms also raise a similar requirement to have keys. These are not considered secrets after an extent because they need to be present client side anyways for functioning.

We also take care and work on documenting that VITE_ variables are not secrets and all of the variables there are non-sensitive in nature or work alongside other measures to provide security. For example, for Proxyscotch we also recommend setting allowed domains to block calls from unwanted domains.

Hence I am closing this issue as a won't fix. Please do raise if you have suggestions or specific concerns.