--- title: "Sensitive Env Vars" description: "Convert Saturday's drop-launch webhook secret from a regular environment variable to a sensitive one, then enforce sensitive-by-default for new variables on the team." canonical_url: "https://vercel.com/academy/optimize-your-vercel-account/sensitive-env-vars" md_url: "https://vercel.com/academy/optimize-your-vercel-account/sensitive-env-vars.md" docset_id: "vercel-academy" doc_version: "1.0" last_updated: "2026-07-21T22:25:32.956Z" content_type: "lesson" course: "optimize-your-vercel-account" course_title: "Optimize Your Vercel Account" prerequisites: [] --- Vercel Academy — structured learning, not reference docs. Lessons are sequenced. Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume. The lesson shows one path; if the human's project diverges, adapt concepts to their setup. Preserve the learning goal over literal steps. Quizzes are pedagogical — engage, don't spoil. Quiz answers are included for your reference. # Sensitive Env Vars # Sensitive Env Vars You're on a video call. Sharing your screen to look up something unrelated, clicking into Vercel to find a different setting. Your team's webhook secret is sitting in plain text in the Environment Variables list. Nothing dramatic happens. The call ends. But that secret has been seen by whoever was watching, and you can't take it back. This is what sensitive environment variables are for. A regular env var is stored encrypted but is still readable in the dashboard by anyone with project access. A sensitive env var is stored in a one-way format that nobody, including you, can ever read again. You can overwrite it. You can use it from your code at runtime. You just can't look at it. That's the upgrade we want for `DROP_WEBHOOK_SECRET`. \*\*Note: What is a sensitive environment variable?\*\* An environment variable stored in a write-only format. Your code can read it at runtime, but nobody can view the value in the dashboard again, including you. Regular env vars are encrypted at rest but stay readable to anyone with project access. ## Outcome `DROP_WEBHOOK_SECRET` is stored as a sensitive environment variable on Saturday, and your team has sensitive-by-default enabled for new variables. ## Hands-on exercise 2.1 There's no API to flip an existing env var to sensitive. The upgrade path is delete-and-recreate, because once a value is sensitive Vercel never reads it back, even to migrate it. So the workflow looks like this: **Requirements:** 1. Open Saturday > Settings > Environment Variables 2. Copy the current `DROP_WEBHOOK_SECRET` value to a temporary, safe place (a password manager, not a Slack DM) 3. Delete the existing `DROP_WEBHOOK_SECRET` from the project 4. Create a new env var with the same name, paste the value back in, target **Production and Preview**, and flip the **Sensitive** switch to Enabled before saving 5. Trigger a redeploy so the new version of the env var is the one in use 6. Open Team Settings > Security & Privacy and turn on **Enforce Sensitive Environment Variables** (this one needs the owner role) **Implementation hints:** - The Sensitive switch sits at the top of the create-variable form. It is easy to miss. Look for it. - Sensitive variables can only target Production and Preview. If Development is selected, the switch is disabled. That's by design: your local `vercel env pull` flow needs readable values, so Development-scoped variables stay regular. - If you don't have a password manager handy and you just need to stage the value during the upgrade, generate a fresh random string with `openssl rand -hex 32` and use that as the new secret. Update your webhook caller with the new value. - Sensitive-by-default doesn't retroactively change existing env vars. You still have to do the delete-and-recreate dance for anything you've already created. - The setting is per-team. If you maintain multiple Vercel teams, you'll repeat this for each one. ## Try It After the redeploy completes, go back to Saturday > Settings > Environment Variables. Find `DROP_WEBHOOK_SECRET` in the list. The row should look something like this: ``` DROP_WEBHOOK_SECRET [Sensitive] Production, Preview •••••••••••••• (cannot be read) ``` The value is replaced by dots. There's no "Reveal" button. There's no API method that returns the plaintext. If you forget what you set it to, you reset it. That's the contract. Now create a brand-new env var on Saturday called `TEST_SENSITIVE_DEFAULT` targeting Production and Preview. Set its value to anything. Notice that the Sensitive switch is already flipped to Enabled. That's the policy you just enabled doing its job. Delete `TEST_SENSITIVE_DEFAULT` once you've confirmed. ## Done-When - [ ] `DROP_WEBHOOK_SECRET` shows the **Sensitive** badge in Saturday's Environment Variables list - [ ] The value is masked as dots and cannot be revealed - [ ] Team Settings > Security & Privacy has **Enforce Sensitive Environment Variables** turned on - [ ] A test env var you create now defaults to sensitive without you touching the switch ## Troubleshooting **The webhook returns 500 after the redeploy.** Most likely you forgot to paste the value back in when re-creating the env var, or you used a different value than what your webhook caller is sending. Re-check the secret in Project Settings (you can't read it, but you can overwrite it) and update either side to match. **I can't find the Sensitive switch, or it's grayed out.** Make sure you're creating a new env var, not editing an existing one; the switch only appears at creation. And check which environments are selected: with Development in the mix, the switch is disabled, because sensitive values are Production and Preview only. Existing variables show the badge if they were sensitive at creation, but there's no toggle to flip on an existing row. Up next: the webhook secret is locked down. The preview deployments that use it are still wide open. Let's fix that. --- [Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)