If “Vibe Coding” democratized creation, it also democratized the risk of shipping Vulnerable Infrastructure (S). When an LLM generates a component, it doesn’t always consider the Content Security Policy (CSP) or the origin of a request.
The Zero-Trust API Key
In Phase 3 of the ProductBees build, we realized that we needed more than just a “Site Password.” We needed a Zero-Trust Entity Identifier.
We implemented a PB-API-KEY system backed by:
- D1 Persistence: Every agent has a unique record, allowing for instant revocation and granular rate-limiting.
- SHA-256 Hashing: We never store raw keys. We store cryptographic hashes using the Web Crypto API, ensuring that even if our database is compromised, your keys are not.
- Prefix-based Lookup: By using the first 12 characters (
pb_live_xxxx) as a prefix, we can perform high-speed lookups in D1 without scanning every record.
Automating the Shield (CSP)
One of the most common security failures in modern apps is a broken or missing Content Security Policy. It’s hard to maintain manually, especially when you have dynamic nonces.
We automated this in our build.ts script. During every deployment:
- We generate a fresh cryptographic nonce.
- We perform a global regex replacement across all production headers.
- We inject that nonce into our JS islands.
This means that Cross-Site Scripting (XSS) isn’t just “unlikely”—it’s architecturally prevented by the build engine itself.
Trust is the New Moat
In a world where anyone can clone your UI in 5 minutes, your Security (S) is what tells a partner, “We are a safe place for your data.”
The Lesson: If your headers don’t strictly enforce origin and your keys aren’t hashed, you’re not building a platform. You’re building a demo.
[!CAUTION] Audit Dimension: Security (S) Are you storing raw API keys in plain text? If so, your Security score is a 0. There is no “vibe” that covers for a plain-text credential leak.
Next: Part 6 — From Demo to Infrastructure The 6 stages of the Maturity Model — and how to walk across the bridge.