FixVibe

// docs / security guides / pre-ship checklist

Checklist di sicurezza vibe coding: 44 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-distribuzione (controlla la tua origine). DEPLOY = al momento della distribuzione. POST = verifica post-distribuzione. Gli elementi fanno riferimento a FixVibe, controlla gli ID nel modulo category.check-id, ove pertinente.

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.browser-storage 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 — Force RLS on every public.* table. In Supabase: ogni tabella deve avere ALTER TABLE ... ENABLE ROW LEVEL SECURITY e FORCE ROW LEVEL SECURITY. Force è importante: senza di esso, Postgres ignora RLS per i proprietari di tabelle.
  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 baas.supabase-rls 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 active.auth-flow e active.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 headers.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 discovery.tech-fingerprint. 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. discovery.platform-vercel 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 o HTTP verifica del file. Ciò sblocca le nuove scansioni pianificate, il sondaggio attivo e il monitoraggio delle minacce in tempo reale.
  2. Schedule passive re-scans. Pro i piani supportano una cadenza di 3 ore; Unlimited supporta la cadenza di 6 ore. Ogni scansione pianificata che fa emergere una nuova scoperta attiva un'e-mail (e un webhook se ne hai collegato uno).
  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. Differenze nel registro della trasparenza dei certificati, DNS modifiche, JS fughe di informazioni segrete sui bundle, elenchi di informazioni sulle minacce: vengono attivati nel momento in cui vengono rilevati, non alla successiva scansione pianificata.

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.

Incolla una URL — FixVibe esegue ogni controllo passivo di questa guida più 200 altri in meno di un minuto. Gratis, senza installazione, senza carta.

  • 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.
Checklist di sicurezza vibe coding: 44 voci prima del deploy — Docs · FixVibe