3 ms·

The step they seem to be missing is _the entire development process_. If you're using API keys to access stuff, you do it on your backend, there's no excuse fo

The step they seem to be missing is _the entire development process_. 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.

ratww 5y ago
Is is a bit more nuanced than that. This web client needs access to non-secret keys that are passed via environment variables. This is absolutely commonplace. 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.
- greggsy 5y ago
  Great explanation - client side apps often seem to be a bit of a catch-22 in some cases.
  - danenania 5y ago
    It’s crucial to always use an allow-list approach to passing config through to a client.
    - ratww 5y ago
      Yep. Maybe just forbidding enumerating environment variables in the runtime would be enough for this case. However the CI shouldn’t have backend-only private variables available to frontend builds… some separation here would be safer regardless of developer mistakes.
_fat_santa 5y ago
According to the article, they were keeping their environment variables in React's local state. To anyone that works with React professionally, or even on the side, this is so baffling that a team would do this. 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.
- ushakov 5y ago
  > I'm honestly wondering who they hired for the job let me guess: bootcamp graduates? whoever was the cheapest?
  - SomeCallMeTim 5y ago
    Or outsourced to the lowest bidder.
raxxorraxor 5y ago
Yeah, it shouldn't reach the client in any case. But providing secrets to applications isn't really a well solved problem in my opinion. Even if it is just an environment variable for the server process it could get exposed. 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.
- SomeCallMeTim 5y ago
  It's simply software engineering malpractice to have ever sent any of those keys to the client. 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.
akdor1154 5y ago
Being generous, it might also be a fuckup in implementing SSR... maybe. Still a fuckup though.

ratww 5y ago

Is is a bit more nuanced than that. This web client needs access to non-secret keys that are passed via environment variables. This is absolutely commonplace. 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.

greggsy 5y ago
Great explanation - client side apps often seem to be a bit of a catch-22 in some cases.
- danenania 5y ago
  It’s crucial to always use an allow-list approach to passing config through to a client.
  - ratww 5y ago
    Yep. Maybe just forbidding enumerating environment variables in the runtime would be enough for this case. However the CI shouldn’t have backend-only private variables available to frontend builds… some separation here would be safer regardless of developer mistakes.

_fat_santa 5y ago

According to the article, they were keeping their environment variables in React's local state. To anyone that works with React professionally, or even on the side, this is so baffling that a team would do this. 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.

ushakov 5y ago
> I'm honestly wondering who they hired for the job let me guess: bootcamp graduates? whoever was the cheapest?
- SomeCallMeTim 5y ago
  Or outsourced to the lowest bidder.

raxxorraxor 5y ago

Yeah, it shouldn't reach the client in any case. But providing secrets to applications isn't really a well solved problem in my opinion. Even if it is just an environment variable for the server process it could get exposed. 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.

SomeCallMeTim 5y ago
It's simply software engineering malpractice to have ever sent any of those keys to the client. 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.

akdor1154 5y ago

Being generous, it might also be a fuckup in implementing SSR... maybe. Still a fuckup though.