Zero-Secret Architecture: How to Minimize Your Attack Surface

Security audits often focus on whether secrets are stored properly: in a vault, encrypted at rest, scoped to least privilege. Those things matter, but they answer a smaller question than the one founders should be asking. The right first question is: how many secrets do we hold at all? A secret you do not have cannot leak, cannot be rotated wrong, cannot be committed to a public repository at 2am by a tired contractor, and cannot be exfiltrated by a malicious npm package. The cheapest defense is to not need the defense.

Every secret carries three ongoing costs. First, a leak cost: the blast radius if it escapes, measured in dollars (a Stripe live key) or in reputational damage (a mail API key used to phish your customers). Second, a rotation cost: the engineering time to swap it everywhere it is referenced, multiplied by the number of times per year you should be rotating. Third, an audit cost: the documentation, access reviews, and compliance evidence you need to prove you are managing it correctly. Cut the count from forty to six, and you cut those three costs by roughly the same factor.

This is why Pillar tracks its production secret inventory as a single small list rather than as a directory in a vault. The list fits in a sentence: a webhook verification secret in one Cloudflare Worker, a wrangler deploy token on the developer laptop, a registrar API credential held offline, and a small number of similar single-purpose tokens. Each one exists because there was no hosted equivalent we could outsource the boundary to. That number is the number we defend.

Start at the customer's browser. A visitor lands on a Pillar Studio page, reads about a domain, and clicks the buy button. That button is a Stripe Payment Link, which is a URL hosted by Stripe. There is no Stripe API key on the Pillar side of that handoff, because the entire checkout flow runs on Stripe's domain, with Stripe's keys, on Stripe's servers. When the transaction completes, Stripe fires a webhook at a single Cloudflare Worker we run for exactly this purpose, and that Worker verifies the signature using a webhook secret stored only in the Worker's environment variables. The webhook secret has no spending power; it only proves Stripe sent the message.

Now look at the contact form. Visitors who want to reach the team submit through an intake form whose action attribute points at Formspree. Formspree holds the credentials that send the resulting email; the static page on Pillar holds nothing more sensitive than a generic endpoint URL. There is no SendGrid key, no Mailgun key, no SMTP password anywhere on the Pillar side of that flow. If our frontend repository leaked tomorrow, no mail-provider key would leak with it, because no mail-provider key exists.

Deployment uses Cloudflare Pages, driven from a developer laptop by the wrangler CLI. The wrangler token lives in the operator's local keychain and is never shipped to a CI server, a build environment, or a shared machine. The published site is static HTML, CSS, and a handful of JavaScript files; it contains no runtime secrets because there is no runtime to hold them in. Even the deploy credential is short-lived in practice, because rotating it is a one-line CLI command that touches a single keychain entry. The final piece is the domain registrar account at Dynadot, whose credentials are held with the same hygiene as personal banking: long password, hardware-key second factor, no API key issued unless a specific automation needs it.

If you are operating today with the typical 20-to-50 secret inventory, the migration is mostly a matter of replacing each secret-bearing service with a hosted equivalent that holds the secret for you. The order matters: start with the highest-leverage replacements, because each one removes not just a credential but the operational tax that came with it. Replace your server-side Stripe integration with Stripe Payment Links or Stripe-hosted Checkout, and the live key plus the rotation policy plus the PCI scope all leave at once. Replace your custom mail integration with Formspree for intake and a hosted transactional provider's customer-managed templates for outbound, and the mail key plus the bounce monitoring plus the deliverability complexity all leave at once.

The next category to attack is the backend itself. Most startup backends exist because the team assumed they were necessary, not because a specific feature requires server-side state. A surprising fraction of marketing sites, documentation sites, content sites, and even commerce sites can be rebuilt as static deployments on Cloudflare Pages or an equivalent edge platform, with the small dynamic pieces moved into individual Workers or Functions. Each backend you delete takes a database credential, a mail relay credential, and a server SSH key with it. The replacement is often faster, cheaper, and easier to reason about, in addition to being smaller in attack surface.

Last, deal with the secrets you cannot eliminate. For each remaining credential, ask three questions: what is the smallest environment that can hold it, how short can its lifetime be, and what is the blast radius if it leaks? A Stripe webhook secret belongs in one Worker's environment, rotates quarterly, and on leak only allows an attacker to forge webhook traffic to one endpoint. A wrangler deploy token belongs only on a developer laptop, rotates whenever a teammate leaves, and on leak only allows an attacker to deploy code (which your code review process catches). A registrar API key, if you use one, belongs offline and is only loaded into memory for the duration of a specific automation run. These boundaries do not eliminate the secret, but they convert it from a permanent liability into a contained one.