31–40 of 131 posts
I'm not sure I've seen it mentioned yet that when Vercel rolled out their environment variable UI, there was no "sensitive" option https://github.com/vercel/vercel/discussions/4558#discussion... . There was ~2 years or more until it was introduced https://vercel.com/changelog/sensitive-environment-variables...
I'm not sure I've seen it mentioned yet that when Vercel rolled out their environment variable UI, there was no "sensitive" option https://github.com/vercel/vercel/discussions/4558#discussion... . There was ~2 years or more until it was introduced https://vercel.com/changelog/sensitive-environment-variables...
The only way to defend against these types of issues is to encrypt your environment with your own keys, with secrets possibly baked into source as there are no other facilities to separate them. An attacker would need to not only read the environments but also download the compiled functions and find the decryption keys.
It is not ideal but it could work as a workaround.
What bites people: rotating a vercel env variable doesn't invalidate old deployments, because previous deploys keep running with the old credential until you redeploy or delete them. So if you rotated your keys after the bulletin but didn't redeploy everything, then the compromised value is still live. Also worth checking your Google Workspace OAuth authorizations. Admin Console > Security > API Controls > Third-part…
I'm not sure I've seen it mentioned yet that when Vercel rolled out their environment variable UI, there was no "sensitive" option https://github.com/vercel/vercel/discussions/4558#discussion... . There was ~2 years or more until it was introduced https://vercel.com/changelog/sensitive-environment-variables...
Sensitive does not mean it is not readable. It is just simply not exposed through the UI. It can be easily leaked if you return a bit too much props from the action functions or routes. The only way to defend against these types of issues is to encrypt your environment with your own keys, with secrets possibly baked into source as there are no other facilities to separate them. An attacker would need to not only read…
please don't suggest this. The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM (with machine level identify managed by the parent platform)
This is how Google Secrets or AWS Vaults work.
What bites people: rotating a vercel env variable doesn't invalidate old deployments, because previous deploys keep running with the old credential until you redeploy or delete them. So if you rotated your keys after the bulletin but didn't redeploy everything, then the compromised value is still live. Also worth checking your Google Workspace OAuth authorizations. Admin Console > Security > API Controls > Third-part…
Usually rotating a credential means that you invalidate the previous one. Never heard of rotating credentials that would only create new ones and keep the old ones active.
> OAuth trust relationship cascaded into a platform-wide exposure > The CEO publicly attributed the attacker's unusual velocity to AI > questions about detection-to-disclosure latency in platform breaches Typical! The main failures in my mind are: 1. A user account with far too much privileges - possible many others like them 2. No or limited 2FA or any form of ZeroTrust architecture 3. Bad cyber security hygiene
Blaming AI is gonna be the security breach equivalent to blaming ddos when your website breaks isn't it.
Earlier quoted context omitted.
Sensitive does not mean it is not readable. It is just simply not exposed through the UI. It can be easily leaked if you return a bit too much props from the action functions or routes. The only way to defend against these types of issues is to encrypt your environment with your own keys, with secrets possibly baked into source as there are no other facilities to separate them. An attacker would need to not only read…
> with secrets possibly baked into source please don't suggest this. The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM (with machine level identify managed by the parent platform) This is how Google Secrets or AWS Vaults work.