I wrote a post earlier today about cleaning up after the Vercel breach. The cleanup itself is easy — ten minutes, a sequence of clicks, done.
What's been bugging me all afternoon is a different question:
Why is "sensitive" opt-in?
The implicit default is wrong
When you add an env var to Vercel, it's not marked sensitive by default. You have to remember to toggle it.
This is the wrong default for a class of values where 99% of the time, "sensitive" is what you want.
Think about the actual population of env vars in any real project:
- API keys for third-party services — sensitive
- Database URLs — sensitive
- Signing secrets — sensitive
- Stripe keys, Auth0 secrets, etc — sensitive
- Feature flags — occasionally sensitive
- Config booleans — usually not sensitive
- Public API base URLs — not sensitive (they're in the client bundle anyway)
For most teams, the split is maybe 80/20 in favor of "should be sensitive." Maybe 90/10.
A default that matches 10-20% of cases is a design mistake.
Why the default exists
Vercel has a specific technical reason: sensitive env vars can't be read after they're set. You can only overwrite or delete. This makes debugging harder when you're troubleshooting "is the value what I think it is?" The opt-in default gives you a debugging escape hatch.
Fine. But the escape hatch should be the exception, not the default. Debugging an env var value is maybe 1% of the time you interact with env vars. Protecting against leaks is 100% of the time.
Moving from "default not-sensitive, opt-in sensitive" to "default sensitive, opt-out for debugging" would match the actual weight of the two concerns.
The minimal workflow change
I can't change Vercel's default. I can change my own habit.
Before today: add env var, fill in value, save. Maybe remember to toggle sensitive. Maybe not.
After today: add env var, fill in value, sensitive ON, save. If I later need to debug, I'll flip it off, verify, flip it back.
The cost is two extra clicks at creation time. The benefit is that every future breach like today's is a non-event.
Generalizing: safe defaults for tiny projects
There's a broader principle here. Small projects skip security hygiene because the perceived cost-benefit is wrong:
- "I have no users, who'd target me?" — but breaches are opportunistic, not targeted
- "I'll tighten security when I scale" — but by then you have user data in the loss radius
- "Defaults are too paranoid for my usecase" — but defaults are designed for the median case, which is probably you
The fix isn't to be paranoid. The fix is to use tools' safest defaults and only opt out when there's a specific reason. Think of it as borrowing the thinking of a larger team.
Concretely for a solo/indie Next.js + Vercel setup:
- Env vars: sensitive by default. I explained my reasoning above.
- Deployment protection: "Standard" minimum. Blocks preview deploys from being publicly indexed.
- Branch protection on main: requires PR + review even if the reviewer is yourself 24h later. Catches "oh no I just committed the API key" before push.
- Pre-commit hook scanning for secrets: cheap to set up, catches the stupid ones. I wrote a piece about mine — it's a 30-line shell script and it's caught me twice.
- Service-specific secret rotation: quarterly, on a calendar. Not because you expect a breach. Because it bounds the window.
- Separate secrets by environment: production secrets live only in production. Preview and development use their own keys or dummy values.
Each individual control takes five to thirty minutes to set up. None of them are hard.
The meta-lesson
Security defaults are worth thinking about critically because the cost of getting them wrong only shows up asymmetrically — nothing happens 99 times, something catastrophic happens on the 100th.
Most of us outsource this thinking to platform defaults and assume platforms get it right. Today was a reminder that platforms sometimes get it right for the platform, not for you.
Audit your defaults. Pick the ones that cost you two clicks and buy you asymmetric downside protection.
Three cups of tea. No coffee. Sensitive flag ON from now on. Lesson logged.
Top comments (0)