Quoted post unavailable.
Not really?
Kinda really. This entire class of security lapse can be avoided by not building a js app on the client.
iViewed your API keys
31–40 of 116 posts
Re: iViewed your API keys
#32Earlier quoted context omitted.
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 appl…
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 prob…
Great explanation - client side apps often seem to be a bit of a catch-22 in some cases.
Re: iViewed your API keys
#33To be fair, I think a lot of developers begin with that. There is a logistical problem in providing secrets to a process without getting the secret exposed. Environment variables are an often chosen approach. Of course when the software is tested and ready to be deployed, the step to use a secure container containing credentials is often neglected like it was probably done here. This isn't necessarily sloppy programm…
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 appl…
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.
Re: iViewed your API keys
#34Re: iViewed your API keys
#35Earlier quoted context omitted.
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 appl…
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.
> I'm honestly wondering who they hired for the job
let me guess: bootcamp graduates? whoever was the cheapest?
Re: iViewed your API keys
#36I'm not sure how bad this actually is. I haven't examined all the env variables exposed, but it's fairly common to expose public-facing api keys for services that require client-side communication with a 3rd party API. E.g. for client-side bug tracking, search etc.
Re: iViewed your API keys
#37*.id.au is an interesting domain that I haven’t seen before. Apparently you can get an id.au iff you’re an Australian citizen, and it must approximately match your real name.
Re: iViewed your API keys
#38Earlier quoted context omitted.
Completely agree. The AU Gov would probably call this hacking
Quite a few countries have laws from the 1980s that basically say "gaining unauthorised access to computer systems is a crime" Which is of course a very expansive definition. Think you've found a leaked database credential and you test it before reporting, so as not to create a false alarm? That's illegal hacking. Almost any persistent XSS? That's illegal hacking. Access an admin panel by entering a default password?…
In Australia the goto for dropping a legal hammer on a digital crime is "misuse of a carriage service" which is just a big lasso that puts crimes like fraud that happen on the internet into a simple basket so they can attach sentences as they see fit.
Re: iViewed your API keys
#39I'd be careful about posting stuff like this as a young person in Australia. The modern situation is incredibly hostile towards this sort of disclosure. Especially regarding a government entity. It's not that you've done anything in the slightest bit wrong. It's that others with power can easily make it become wrong with little to no backlash in the current Australian climate. I understand the desire for recognition,…
I booked a hotel stay (in Canada, not Australia) and got an error page at some point that dumped out all env vars including database credentials. Tried my best to report (not publicly disclose) it, including asking the front desk for contact information for IT; no response. I think we're (on HN) often in quite a bubble of being (or striving to be) hot on this sort of thing, or frankly far trickier to exploit sorts of…
Most C-level people couldn't care less about security. I'm yet to work for a SaaS that implements 2FA, yet at some point all of them have had passwords that a script kiddie could brute force within an hour. The only time I've seen security become a top-level priority was when some customer demanded some kind of checkbox compliance like SOC / ISO27001.
Re: iViewed your API keys
#40I'm not sure how bad this actually is. I haven't examined all the env variables exposed, but it's fairly common to expose public-facing api keys for services that require client-side communication with a 3rd party API. E.g. for client-side bug tracking, search etc.
If it is a paid service other can now use the service while you pay the price.
And the API might also expose data you don't want to expose to the public.
That's why you never put these on the client side. There are better options, for example a proxy that injects tokens into the header.