If you're using API keys to access stuff, you do it on your backend, there's no excuse for that stuff to make it to the frontend.
If your "client" needs access to sensitive API keys, you need to rethink your architecture.
As a (senior) backend software engineer, this reeks of a person/team who doesn't know how to architect and/or implement web applications/software.
I'm honestly wondering who they hired for the job. Because this is one of the most fundamental failings in security I've ever seen.
let me guess: bootcamp graduates? whoever was the cheapest?
However there are two real issues here: first, some bug in the code is causing all environment variables to be dumped into the JS bundle. You can see that in inane keys like PATH, HOME, PORT.
This issue wouldn't be such a huge problem by itself. The second problem is that during the build process for the frontend, there are environment variables that shouldn't be there, such as the secret ones. The CI or build machine should have been well isolated enough to prevent this problem from happening.
This is a problem in the CI coupled with a bad build process.
However the CI shouldn’t have backend-only private variables available to frontend builds… some separation here would be safer regardless of developer mistakes.
If a clients needs an API key I would think to route the requests through the server and add the key information at that point, but I am not a web developer and not sure if that always scales for any use case.
There is no excuse.
It is a well-solved problem to handle secrets; there are better and worse solutions. An environment variable for a server can get exposed if the server is hacked; a secret sent to a client is exposed the second the server goes live. One of these is much worse than the other.
There are also better solutions than environment variables. A competent team would be aware of many options. Whoever coded this is not competent, full stop. It's not that they didn't finish; these services should never have accessed from the client at all.