In early 2023, Vercel disclosed a breach where attackers exploited an OAuth integration with a third-party application to steal tokens. Those tokens then granted access to environment variables across dozens of customer projects. This incident wasn't a sophisticated zero-day exploit—it was a supply chain attack that leveraged the very integrations developers rely on to streamline deployments. When an OAuth token is compromised on a platform like Vercel, it can expose API keys, database credentials, and other secrets stored in environment variables. The same attack vector applies to any platform that uses OAuth for third-party integrations. In a world where CI/CD pipelines and cloud services are interconnected, a single stolen token can cascade into a full credential leak. This article breaks down what went wrong during the Vercel breach and, more importantly, provides practical, mistake-based lessons to help developers, DevOps engineers, and founders secure their own deployment pipelines. You'll learn how to harden environment variable management, implement OAuth security best practices, detect supply chain attacks early, and respond effectively if secrets are exposed. By the end, you'll have a clear checklist to prevent the same vulnerabilities from impacting your projects.
The Anatomy of the Vercel Breach: What Went Wrong
The Vercel breach of 2022 revealed a dangerous attack vector that bypassed direct platform defenses. The attackers did not target Vercel's core infrastructure. Instead, they compromised a third-party OAuth integration—a common practice where developers connect external services like GitHub, GitLab, or monitoring tools to Vercel.
Here is how the attack unfolded:
OAuth Token Theft: The attacker gained control of a third-party app that had been granted access to a Vercel account via OAuth. This app held a valid OAuth token that allowed it to interact with Vercel's API on behalf of the user. The token was stolen through a vulnerability in the third-party service itself, not Vercel.
Environment Variable Exposure: Once the attacker possessed the token, they used Vercel's public API endpoints (e.g.,
GET /v6/projects/{projectId}/env) to read environment variables—including API keys, database credentials, and secrets—across all projects accessible to that token. Because the token had broad permissions, no additional authentication was required.Lack of Scoped Permissions: The critical misstep was that Vercel's OAuth implementation did not enforce fine-grained scopes for environment variable access. A single token could read every project's secrets, even if the third-party app only needed access to deployment logs. This violates the principle of least privilege.
Oversight of Connected Apps: Many developers had no visibility into which third-party apps held active tokens or what permissions those tokens had. There was no dashboard to review and revoke integrations easily, and no alerts when a token was used to access sensitive data.
The lesson is clear: every integration—especially OAuth-based ones—must be scoped to the minimum necessary permissions, and developers must audit connected apps regularly to remove unused or overly permissive tokens.
Common Mistakes When Managing Environment Variables
Even experienced developers make preventable errors that can expose environment variables. Here are the most dangerous ones:
- Hardcoding secrets in source code or config files. Storing API keys, database passwords, or OAuth tokens directly in your codebase is a recipe for disaster. Code often ends up in shared repositories, CI logs, or even public containers. Instead, always use a secrets manager or platform-specific environment variable storage (e.g., Vercel’s dashboard or AWS Secrets Manager).
- Sharing .env files over insecure channels. Email, Slack, or messaging apps are not encrypted end-to-end. An .env file sent via Slack can be indexed and leaked. Use encrypted file sharing, password managers, or a secrets vault to distribute secrets.
- Not rotating API keys or tokens regularly. Static secrets that never change are vulnerable if leaked. Even without a known breach, regular rotation limits the window of exposure. Automate rotation with tools like HashiCorp Vault or cloud provider features.
- Logging environment variable values in plaintext. Debug logging, error reports, or stack traces often include environment variables. Attackers monitoring logs can collect secrets instantly. Sanitize logs by filtering known environment variable names before output.
- Using the same secrets across different environments (dev, staging, prod). A developer’s local environment is far less secure than production. Stolen dev credentials can lead to production compromises. Use separate, scoped secrets per environment and enforce this with CI/CD policies.
The consequences: data breaches exposing user information, unauthorized access to internal systems, and full supply chain compromise if tokens are reused in third-party integrations. Each of these mistakes is how real breaches—including the Vercel incident—occur.
Practical Steps to Secure Environment Variables in Your Deployment Pipeline
Now that you've seen how missteps like unsecured OAuth tokens and over-permissioned integrations can expose environment variables, it's time to lock down your own deployment pipeline. The following steps give you a concrete, repeatable approach to protecting secrets—whether you deploy on Vercel, Netlify, AWS, or another platform.
1. Use a Secrets Manager
Stop storing sensitive values directly in platform dashboards or .env files that get committed. Instead, adopt a dedicated secrets manager such as AWS Secrets Manager, HashiCorp Vault, or Doppler. These tools encrypt secrets at rest and in transit, provide automatic rotation, and log every access attempt. For example, with Doppler you can define a single source of truth for all environments and inject secrets into your build step via CLI or API—never leaving them in your codebase.
2. Encrypt Environment Variables at Rest and in Transit
Most cloud platforms encrypt environment variables at rest by default, but you should also ensure that secrets are encrypted when moving between systems. If you must store variables in a file (e.g., for local development), use an encrypted format like .env.encrypted with a tool like sops or git-crypt. For CI/CD pipelines, pass secrets through the platform's encrypted environment variable system rather than hardcoding them in configuration files.
3. Adopt Environment-Specific Variables and Avoid Overlap
Never reuse the same API key, database credential, or OAuth token across development, staging, and production environments. If one environment is compromised, the attacker gains access everywhere. Create distinct variables per environment using naming conventions (e.g., DB_PASSWORD_PROD, DB_PASSWORD_STAGING) or separate projects in your secrets manager. This also makes rotation safer and easier.
4. Enforce Access Control
Limit who and what can read your environment variables. On Vercel, for example, you can restrict environment variable visibility to specific teams or use protected deployments so preview branches only get a subset of variables. In AWS Secrets Manager, define IAM policies that allow only the necessary services (like a build runner) to decrypt secrets. Apply the principle of least privilege: every service or user should have the minimum permissions needed.
Example: Configuring Encrypted Env Vars in Vercel
Vercel offers two main ways to set environment variables: through the Dashboard or via a .vercel.env file. The dashboard stores variables encrypted at rest, but they are visible to team members with project access. The .vercel.env file is not encrypted by default—it's just a plaintext file that Vercel reads during builds. For production use, avoid the file method for secrets. Instead, use the dashboard with strict team permissions, or better yet, pull secrets from a remote secrets manager during the build step (e.g., using a vercel.json build command that fetches from Doppler). This keeps secrets out of Vercel's storage entirely and gives you full control over access and rotation.
By implementing these practices, you drastically reduce the attack surface that enabled the Vercel breach. Tools like Paradane can help enforce these policies across your team's deployment pipelines, ensuring that every environment variable follows the same security baseline.
OAuth Integration Security Best Practices
The Vercel breach demonstrated how a single overly permissive OAuth scope can expose every environment variable across an entire deployment platform. When you integrate a third-party OAuth application with your deployment pipeline, you are granting that application a set of permissions that can be abused if not tightly controlled. Follow these best practices to minimize risk.
Principle of Least Privilege for OAuth Scopes
Request only the scopes your integration genuinely needs. In the Vercel incident, the attacker used a token that had broad read access to environment variables. If the third-party app had been scoped to only read specific projects or deployment logs, the blast radius would have been much smaller. Audit your OAuth scopes regularly and remove any that are not absolutely required.
Validate and Whitelist Redirect URIs
Always validate redirect URIs against a whitelist. Attackers can exploit open redirectors to intercept authorization codes. Whitelist exact URIs (including protocol, domain, and path) for each integration. Reject any callback that does not match exactly.
Store Tokens Securely
Access tokens and refresh tokens must be encrypted at rest and in transit. Store them in a dedicated secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) rather than in plaintext configuration files. Use short-lived access tokens and rotate refresh tokens frequently. Integration platforms like Vercel now support encrypting environment variables, but tokens passed via OAuth need the same level of protection.
Monitor for Unusual Token Usage
Enable logging and monitoring for token creation, usage, and revocation. Look for patterns such as a token being used from an anomalous IP range, at unusual hours, or for accessing resources outside its intended scope. Set up alerts for unexpected API calls.
Common Pitfall: Overly Broad Scopes
Developers often grant read:env or write:env scopes to third-party OAuth apps for convenience. Instead, scope tokens to the exact actions needed, such as reading build logs or triggering deployments, and never expose environment variable access by default. Review each integration’s permissions on your deployment dashboard.
By applying these controls, you can prevent a compromised OAuth token from becoming a supply chain entry point, just as happened to Vercel.
Incident Response and Monitoring for Supply Chain Attacks
Even with the best prevention measures, a determined attacker can slip through. The Vercel breach proved that a single compromised OAuth integration could expose every environment variable tied to an account. That’s why having an incident response plan focused on supply chain attacks is not optional—it’s essential.
Proactive monitoring starts with logging and alerting. Enable audit logs on your deployment platform and monitor for abnormal API calls, such as a sudden spike in environment variable reads from an unfamiliar IP or unusual OAuth token usage. Set up webhook-based alerts (e.g., to Slack) when a new OAuth app is connected to your account, when an existing app’s permissions change, or when environment variables are accessed outside your usual deployment flow. For example, a Slack notification that fires whenever a new third-party app receives OAuth access can help catch malicious integrations early.
Regular audits of connected applications and permissions are critical. Schedule a quarterly review of all OAuth integrations, their scopes, and the users who authorized them. Revoke any that are unused or have overly broad permissions. Tools like GitHub’s “OAuth Apps” page or Vercel’s “Connected Accounts” panel allow you to see and manage these connections.
Have a rotation plan ready to execute instantly. Maintain a list of all environment variables and OAuth tokens, their locations, and who can rotate them. When a compromise is suspected—such as a notification of anomalous access or a leaked token—immediately revoke the affected credentials, rotate them to new values, and update all dependent services. Automate this where possible using secrets managers with built-in rotation policies (e.g., AWS Secrets Manager or HashiCorp Vault).
After any suspected exposure, conduct a postmortem. Document the timeline, the root cause, the scope of affected secrets, and what was done to remediate. Then update your security policies—tighten scopes, add additional monitoring, or restrict API access further. The Vercel breach, for instance, led many teams to require user-level approval for any OAuth app requesting access to environment variables.
Finally, practice the plan. Run tabletop exercises where a team member simulates a compromised OAuth token and the response team must detect, contain, rotate, and document. This makes the process second nature when a real incident occurs.
Putting Security into Practice: Your Next Steps
You now have a clear picture of how attackers exploit environment variables and OAuth integrations—and a practical playbook to prevent it. The most important step is to turn this knowledge into action. Start today by auditing your current deployment security posture using the checklist from this article.
Begin with a simple audit: list every OAuth app connected to your deployment platform (Vercel, Netlify, GitHub, etc.). For each integration, review its requested scopes and confirm it cannot read environment variables unless absolutely necessary. Revoke any unused or overly broad tokens. Next, examine how your team manages secrets: are they stored in a secrets manager, rotated regularly, and never logged in plaintext? If not, those are immediate fixes.
Apply these lessons to a real project—perhaps a CI/CD pipeline you maintain. Replace hardcoded environment variables with a secrets manager, enable encryption at rest, and enforce least-privilege access. For teams that need expert guidance implementing these practices, Paradane (https://paradane.com) provides resources to help secure your deployment workflows. But the most critical step is to start now. Treat every environment variable as a potential attack vector and every OAuth token as a key to your infrastructure. Your future self—and your users—will thank you.
Top comments (0)