FixVibe

// docs / security guides / pre-ship checklist

Checklist di sicurezza vibe coding: 51 voci prima del deploy

Un pratico elenco di controllo organizzato in fasi per le app create con Cursor, Claude Code, Lovable, Bolt, v0, Replit e Windsurf. Ogni elemento è utilizzabile in meno di cinque minuti. Eseguilo prima di passare alla produzione, quindi di nuovo prima di ogni versione principale. Gli elementi sono raggruppati in sette categorie (segreti, database, autenticazione, intestazioni, terze parti, distribuzione, monitoraggio) e contrassegnati con la fase di distribuzione a cui si applicano.

PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

Segreti e chiavi API (8 articoli)

Le chiavi hardcoded sono il risultato più comune nelle app con codifica Vibe. Otto elementi per tenerli lontani:

  1. PRE — Audit NEXT_PUBLIC_ env vars. Tutto ciò che ha il prefisso NEXT_PUBLIC_ viene fornito nei bundle client. Se una è una chiave Supabase service_role (decodifica in JWT con "role":"service_role"), eliminala e instradala attraverso un client solo server (src/lib/supabase/service.ts con import 'server-only').
  2. PRE — Grep for hardcoded provider keys. Sorgente di ricerca per sk_live_, pk_live_, STRIPE_SECRET, sk-ant-, sk-, AIza, AKIA e JWT-cerca stringhe (eyJ). Sposta ogni risultato in .env.local e fai riferimento tramite process.env.* solo sul lato server.
  3. PRE — Verify .gitignore. Conferma .env*.local, .npmrc, .yarnrc e tutti i file delle credenziali specifiche del provider verranno ignorati. Esegui git ls-files reindirizzato attraverso i modelli del tuo provider per trovare qualcosa già impegnato.
  4. PRE — Scan the built bundle. Esegui npm run build, quindi grep .next/static e qualsiasi output dist/ per gli stessi modelli. Se una chiave raggiunge il bundle, lo sviluppatore non ha mai avuto una separazione ambientale pulita.
  5. DEPLOY — Set secrets per environment. Vercel: Impostazioni → Variabili d'ambiente, ambito ciascuno a Produzione / Anteprima / Sviluppo. Non condividere mai sk_live_* con l'ambiente Anteprima. Utilizza l'archiviazione env-var crittografata di Vercel, non i segreti del flusso di lavoro in linea.
  6. DEPLOY — Disable build-log secret echo. Alcune configurazioni CI echo variabili env durante la compilazione. Controlla i flussi di lavoro delle azioni vercel.json, GitHub o le impostazioni delle pagine Cloudflare per eventuali echo $SECRET che inseriranno il valore nei log di build pubblici.
  7. POST — Run a passive scan. Il livello Free di FixVibe copre questo: incolla il URL distribuito, attendi ~20 secondi, cerca i risultati secrets.*. Il controllo Secrets in JavaScript Bundles cattura le chiavi che sono finite in localStorage o sessionStorage a causa di un uso improprio di SDK.
  8. POST — Rotate any key that ever shipped. Se una chiave è rimasta in un pacchetto pubblico anche per pochi minuti, considerala compromessa. Ruota le chiavi del ruolo di servizio Supabase tramite la dashboard, rigenera le chiavi limitate Stripe, revoca le chiavi Anthropic/OpenAI/Google tramite le rispettive console.

Controllo dell'accesso al database: RLS e regole Firestore (6 elementi)

BaaS le impostazioni predefinite sono volutamente permissive, quindi il primo tutorial funziona. Prola produzione necessita di politiche esplicite.

  1. PRE — Enable RLS on every public.* table. In Supabase: each table needs ALTER TABLE ... ENABLE ROW LEVEL SECURITY plus explicit policies for each role. RLS is what stops the anon and authenticated API roles; FORCE ROW LEVEL SECURITY only extends it to the table owner and is optional defence in depth.
  2. PRE — Write a policy per (table, role, action). Minimo: una polizza SELECT che aderisce il auth.uid(). Meglio: separare le politiche INSERT / UPDATE / DELETE in modo che un UPDATE non possa introdurre di nascosto modifiche user_id che reindirizzino la proprietà.
  3. PRE — Replace default Firebase rules. Le regole predefinite della modalità test leggono allow read, write: if true;. Sostituisci con regole associate all'autenticazione per raccolta: match /users/{userId} con allow read, write: if request.auth.uid == userId;
  4. PRE — Lint migrations in CI. Esegui supabase db lint o un equivalente prima di unire. CI dovrebbe fallire la compilazione se a CREATE TABLE public.* manca una policy RLS corrispondente.
  5. DEPLOY — Confirm RLS survived deploy. Ricontrolla in Supabase Studio dopo la distribuzione: Tabelle → ogni riga → RLS l'interruttore è ON. Production le migrazioni dei database occasionalmente superano i file delle policy; verificare che la politica sia attiva.
  6. POST — Run an active scan against a verified domain. Il controllo attivo Supabase Row-Level Security scrive su una piccola riga seed utilizzando la chiave anon e segnala se la scrittura è riuscita: i.e. RLS in realtà non sta applicando.

Autenticazione e sessioni (7 elementi)

I bug di autenticazione nelle app codificate AI- tendono ad essere impercettibili: un errore nella verifica del token, un flag HttpOnly mancato, un getSession() dove dovrebbe esserci un getUser().

  1. PRE — Replace getSession() with getUser(). getSession() legge il cookie e si fida di esso; getUser() verifica con il backend Supabase. Sulle rotte del server utilizzare sempre getUser().
  2. PRE — Confirm token expiry. I token Magic-link, di reimpostazione della password e di verifica dell'e-mail necessitano di una scadenza imposta dal server. I collegamenti magici Supabase predefiniti scadono dopo 1 ora: non sovrascriverli con un numero più alto senza un motivo reale.
  3. PRE — Verify JWT aud and exp. Se decodifichi manualmente i token ovunque, controlla entrambe le affermazioni. Meglio: usa getUser() di SDK che lo fa per te.
  4. PRE — Audit cookie flags. I cookie di sessione personalizzati devono essere Secure; HttpOnly; SameSite=Lax (o Strict per flussi non OAuth). Nessun materiale della sessione in localStorage.
  5. PRE — Validate the next redirect param. Il parametro di query next dopo l'accesso deve iniziare con / e non // (reindirizzamento aperto a attacker.example). Rifiuta qualsiasi altra cosa lato server.
  6. POST — Test logout. Accedi, esci, controlla i cookie (DevTools → Applicazione → Cookie). Il cookie di sessione deve essere cancellato nella stessa risposta. Se persiste, il gestore di disconnessione non sta effettivamente distruggendo lo stato lato server.
  7. POST — Active probe. I controlli Auth Flow Defects e Account Enumeration emergono limiti di autenticazione non funzionanti: risposte diverse su "utente esistente" rispetto a "password errata", limite di velocità mancante all'accesso, token di ripristino non firmati.

HTTP intestazioni di sicurezza e politica di sicurezza dei contenuti (6 elementi)

Le intestazioni rappresentano il rafforzamento più economico dell'intera pipeline e quello saltato più costantemente dal codegen.

  1. PRE — Ship a real CSP. Minimo: script-src 'nonce-{NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. No 'unsafe-inline' in script-src. Next.js applica automaticamente il nonce quando il middleware imposta l'intestazione della richiesta x-nonce.
  2. PRE — Add the legacy three. X-Content-Type-Options: nosniff, X-Frame-Options: DENY (o fare affidamento solo su CSP frame-ancestors), Strict-Transport-Security: max-age=31536000; includeSubDomains.
  3. PRE — Tighten Referrer-Policy. L'impostazione predefinita strict-origin-when-cross-origin va bene per la maggior parte delle app. Non spedire unsafe-url o nessuna intestazione.
  4. PRE — Replace Access-Control-Allow-Origin: *. Grep per questo. Sostituisci con una lista consentita di origine esplicita. Ovunque sia * insieme a credentials: include, il browser rifiuterà la richiesta, ma questa non è una difesa contro un backend mal configurato.
  5. DEPLOY — Verify headers post-deploy. Apri DevTools → Rete → fai clic sul documento root → scheda Intestazioni. Dovrebbero essere presenti CSP, HSTS, X-Frame-Options, X-Content-Type-Options. CSP non deve contenere 'unsafe-inline' in script-src.
  6. POST — Run HTTP Security Headers. Il controllo passivo dell'intestazione segnala ogni intestazione mancante con indicazioni per la correzione della piattaforma di distribuzione (Vercel vercel.json, Cloudflare Pagine _headers, Netlify _headers, Next.js middleware).

Integrazioni di terze parti e APIs (5 elementi)

Ogni script che includi è un'esenzione CSP e una potenziale superficie della catena di approvvigionamento. Tratta le terze parti come parte del tuo confine di fiducia.

  1. PRE — Reverse-proxy analytics where possible. PostHog, Plausible, Umami supportano tutti il proxy tramite il tuo dominio (e.g. /api/posthog). Ciò mantiene connect-src sulla stessa origine e sopravvive agli ad-blocker.
  2. PRE — CSP-allowlist the rest. Per Google Analytics, Stripe.js, Sentry, Intercom, GTM e così via, aggiungi le origini di ciascun fornitore alla direttiva CSP corrispondente (script-src per caricatori, connect-src per telemetria, frame-src per iframe, img-src per pixel).
  3. PRE — Use Stripe Checkout, not raw card forms. Stripe Checkout è un reindirizzamento di primo livello; nessuna voce CSP necessaria per lo script. La superficie ospitata PCI risiede interamente nel dominio di Stripe. Lancia il tuo solo se hai una ragione forte.
  4. PRE — Lock package-lock.json in CI. Esegui npm ci (non npm install) nelle build di produzione. Controlla le dipendenze con npm audit o Snyk prima di ogni rilascio.
  5. POST — Watch Technology Fingerprinting. Il rilevamento passivo dello stack tecnologico fa emergere le versioni della libreria visibili a un crawler. Se spedisci un EOL React, jQuery o Bootstrap, FixVibe lo contrassegna e lo collega a CVE noti.

Igiene e infrastruttura di distribuzione (8 elementi)

Il modo in cui distribuisci conta tanto quanto ciò che distribuisci. AI-le applicazioni codificate traggono vantaggio in particolare dal rafforzamento della distribuzione esplicita.

  1. PRE — Disable x-powered-by. In next.config.js: poweredByHeader: false. Rimuove un segnale di divulgazione della versione gratuita.
  2. PRE — Confirm middleware lives at src/middleware.ts. Con il layout della directory src/, Next.js ignora un livello root middleware.ts. Il middleware fuori posto non riesce silenziosamente a impostare CSP / intestazioni di autenticazione / limiti di velocità.
  3. PRE — Sanity-check Vercel deployment protection. Prola produzione dovrebbe essere pubblica; L'anteprima deve essere protetta da password o limitata ai membri dell'organizzazione. Vercel-Specific Exposure riporta la superficie.
  4. PRE — Block dotfile and config probes at the edge. Aggiungi una regola di riscrittura o di negazione per i modelli /.env, /.git/*, /.aws/*, /.next/trace. Vercel restituisce 403 per molti di questi per impostazione predefinita; controllo incrociato.
  5. DEPLOY — Separate environments. Proproduzione, anteprima, sviluppo. Ognuno ha la propria serie di segreti. I tasti live non raggiungono mai l'anteprima, la modalità test Stripe non raggiunge mai Production.
  6. DEPLOY — Enable Vercel Web Application Firewall. Pro e i piani Enterprise includono WAF con regole gestite. Cloudflare Pages ha la modalità Lotta Bot. Entrambi riducono l'abuso degli scanner automatici e il carico di spray password.
  7. POST — Verify TLS configuration. SSL Labs o testssl.sh contro il tuo dominio di produzione. TLS 1.2 minimo, preferisco TLS 1.3, nessuna cifratura debole, HSTS idoneo al precaricamento.
  8. POST — Confirm health-check endpoints are minimal. A /api/health dovrebbe restituire 200 OK senza corpo. Non riprodurre l'ambiente, creare hash o distribuire timestamp senza autenticazione.

Monitoraggio continuo e nuova scansione (4 articoli)

La sicurezza non è un audit pre-nave una tantum. La deriva avviene ad ogni distribuzione.

  1. Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT or HTTP file verification. Active scans require Hobby or above, scheduled scans require Pro or Unlimited, and live threat monitoring requires Unlimited.
  2. Schedule passive re-scans on Pro or Unlimited. Choose an available cadence for your verified domain. Scheduled runs share your scan allowance; enable completion notifications and signed webhooks as needed. A scheduled scan observes the app at run time, not continuously.
  3. Wire outbound webhooks. Account → Webhooks → aggiungi un endpoint HTTPS, iscriviti a scan.completed + finding.created + scan.active_api.first_used. Passa a Slack / Discord / PagerDuty.
  4. Enable live threat monitoring on Unlimited. Periodic certificate, DNS, bundle, and threat-intelligence checks can surface changes between scheduled scans. Coverage and alert timing depend on the signal and successful polling.

Replit Agent

If you build with Replit Agent, also check:

  1. Don't paste keys into the Agent prompt. Add them in Secrets and give the Agent the variable name instead, so the value never appears in generated code or chat history.
  2. Test CORS on the production domain. The preview pane and your deployed URL are different origins. Check your CORS allowlist against the domain users actually load.
  3. Replit Agent sometimes hardcodes test values. L'agente potrebbe generare codice con API_URL = 'http://localhost:5000</code>. Prima della spedizione, sostituire con <code>os.environ[API_URL'].

Firebase Studio

If you build with Firebase Studio, also check:

  1. Test-mode rules are temporary by intent, not by default. Test mode lets anyone read and overwrite data. If the generated rule carries a date cutoff, client access stops on that date; if not, the database stays open. Replace test rules before launch either way.
  2. Security rules protect data, not Hosting. Firestore and Storage rules don't govern what Firebase Hosting serves: everything in the public directory is public. Keep exports, backups and admin pages out of it.

Claude Code

If you build with Claude Code, also check:

  1. PRE — Keep personal Claude Code settings out of git. Commit .claude/settings.json for shared project settings, but keep .claude/settings.local.json out of the repo: Claude Code excludes it from git when it creates the file, so check it if you created it by hand. Session history lives in ~/.claude, outside the project (Claude Code docs).
  2. Bash operations are unverified. Claude Code esegue direttamente i comandi bash. git commit -m "fix" è conveniente, ma se la directory di lavoro ha un file .env e un glob lo include, esegue il commit. Rivedi sempre git diff --cached prima di eseguire il commit di Claude Code.

Prossimi passi

Desideri un contesto educativo sul perché questi elementi sono importanti? Leggi AI-generated code security scanning. Desideri frammenti di codice concreti per ogni passaggio di rafforzamento? Vedere How to secure an app built with AI coding tools.

// scansiona la tua app

Smetti di leggere. Inizia a trovare le falle nella tua.

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • Free tier — 3 scansioni / mese, senza carta.
  • Scansioni passive contro qualsiasi URL — nessuna verifica di dominio.
  • Ottimizzato per Cursor, Claude Code, Lovable, Bolt, v0, Replit.
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
Avvia una scansione gratis →

senza registrazione

Checklist di sicurezza vibe coding: 51 voci prima del deploy · FixVibe