A security checklist for a vibe-coded Web3 application

AI assistants default to the simplest auth pattern that compiles. That pattern is often "check a boolean, let everyone in." Verify the following before merging:

• Every state-changing function has an explicit access-control modifier, not a comment that says 'only owner.'
• Role checks use msg.sender comparison against a stored address, not tx.origin, which can be spoofed by contracts.
• Privileged functions (mint, upgrade, pause, withdraw) are gated by a role contract, not hardcoded to deployer.
• Session tokens are validated server-side on every request, not trusted from a client-supplied header alone.
• Rate limiting protects auth endpoints (login, signup, password reset) from brute-force and credential stuffing.
• JWT tokens, if used, have a short expiry and a refresh-token rotation flow; no long-lived opaque tokens.

AI models routinely paste API keys, private keys, and database URLs directly into source files because that is the pattern they saw most in training data. Before deployment:

• No private keys, API keys, mnemonics, or database passwords appear in source files, committed configs, or test fixtures.
• Secrets are loaded from environment variables or a secrets manager at runtime, never hardcoded.
• The .env file is in .gitignore and a .env.example template documents required variables without values.
• GitHub secrets scanning (or equivalent) runs on every push and blocks merges on detected credentials.
• Deployed contracts do not embed oracle private keys or admin keys; they reference proxy contracts or multisig wallets.
• Frontend code contains no API keys that grant write access; only publishable, read-only keys are exposed.

Vibe-coded deployments often skip verification, proxy patterns, and upgrade safety. Check before going live:

• Contract source is verified on the block explorer (Etherscan, Arbiscan, etc.) with matching compiler settings.
• Upgradeable contracts use a standard proxy pattern (UUPS or Transparent) with the implementation address recorded.
• Initial state (owner, roles, parameters) is set in the constructor or an initializer, not left to defaults.
• A reentrancy guard is applied to any function that calls an external contract or transfers ETH.
• The contract has a tested pause/unpause path and a recovery plan if a vulnerability is found post-deploy.
• Gas limits on external calls are bounded; no unbounded loops over dynamic arrays.

AI-generated APIs often trust client input entirely. The checklist:

• All inputs are validated server-side with explicit type, length, and range checks before processing.
• SQL queries use parameterized statements; no string concatenation of user input into queries.
• External API calls validate response schemas before parsing; no blind JSON.parse on untrusted data.
• CORS policies restrict origins to known frontend domains, not wildcard.
• File upload endpoints validate MIME types and extensions and store files outside the web root.
• Error messages do not leak internal state (stack traces, query text, key names) to the client.

A one-time checklist catches the obvious issues. Vibe-coded applications change daily as developers regenerate sections, add features, and fix bugs. Each change can reintroduce a vulnerability the checklist previously caught.

Veritas RedTeam automates this checklist on every deploy. The Source Engine traces data flows through AI-generated code, the Surface Engine tests the running API, and every finding is fused into a Neo4j attack graph so you see the full exploit path, not just the individual check that failed. Reserve a scoped scan or join the waitlist to run it against your codebase.