Sincere question: how do you actually make this mistake while having the skills to build a web app of this complexity level? All the frontend and full stack frameworks that I’m familiar with try pretty hard to stop you.
I’ve seen people make exactly this mistake with Next.js. IMO React server components is a fantastic tool for losing track of what’s exposed client side and what isn’t.
Next.js makes you prefix env vars with NEXT_PUBLIC_ if you want them to be available client side, and Vercel has warning flags around it when you paste in those keys.
It's obviously not foolproof, but it's a good effort.
That’s env vars, but not actual variables - it’s really easy (if you are not actively context aware) to f.ex. pass a ”user” object from a server context into a client component and expose passwords etc to the client side.
That's a fair point! It definitely feels easier to make that mistake, and anything where context and discipline is required is a good candidate for making some horrifying blunders :)
If you add `import “server-only”` to the file, it will fail to compile if you to use it on the client. React also has more fine grained options where you can “taint” objects (yes that’s the real name).
Yeah, the problem is that these mitigations require the developer to be context aware, ”server-only” only saves you in the positive case where you correctly tagged your sensitive code as such. The default case is to expose anything without asking. I have also seen developers simply marking everything as ”use client” because then things ”just work” and the compiler stops complaining about useState in a server context etc.
A little tired because you didn't sleep well, or worried about a relative in the hospital, or you stubbed your toe that morning and it's distracting... and whoops.
Yes, the answer must be additional processes and procedures. That way, you’ll never make a mistake! /s
Also bizarre to frame this as “unacceptable behavior”, as if whoever is involved was in some way aware of their mistake and/or would say “this is acceptable behavior!” when confronted with it or something.
Humans are gonna human, if you have an environment where you fail to account for this, this will happen. Reminds me of a dev dropping a production database, or the aws engineer who incorrectly entered a command and brought down s3: many things have gone wrong to even be at this point, blaming a human for behaving like a human in an inhospitable environment is silly. Effort is almost always better spent building a system which is safer to operate for the people involved.
I've considered tracing outgoing responses from nginx/traefik/whatever to watch for known API keys. The difficulty would be identifying the keys amongst the noise.
But if they have five security processes that each has a 99% chance of catching a bug, that's still a 1-in-10,000 chance that something will slip through. And I'd wager that a16z has more than 10,000 "components" that goes through those processes.
my guess is internal tool that wasn't expected to be exposed publicly.
additionally, i didn't realize there are tools to automatically discover unreferenced subdomains like this. i would have just assumed security by obscurity
If one person learns this lesson it's good. If it's on the public Internet, best to expect it will be found. Stick it behind an auth wall of some sort.
I've put internal sites behind AWS ALB's plugged into an OIDC provider[1] (Google), which works well.
