Scansione di sicurezza per codice generato da IA: DAST per app vibe-coded

Perché AI-il codice generato richiede una scansione di sicurezza diversa

AI Gli strumenti di codifica vengono addestrati su repository open source su larga scala. I dati di addestramento sono inclinati verso make it work rispetto a make it secure. Da ciò derivano alcuni modelli strutturali:

• Autocomplete bias. Vince l'importazione corrispondente più vicina. Incollare uno snippet Supabase che utilizza la chiave service_role in un file rende quella chiave il suggerimento di completamento automatico nel file successivo, anche nei componenti React lato client a cui non è mai appartenuta.
• No long-term context. Un LLM non ha memoria del tuo ultimo RLS bypass o dell'incidente post mortem della tua squadra. Ogni file generato è nuovo e spesso manca dei modelli difensivi che gli esseri umani porterebbero tra i file.
• Speed as the rewarded metric. Gli utenti lodano la velocità; LLM la formazione lo rafforza. "Genera l'autenticazione Next.js più veloce" batte "genera l'autenticazione Next.js più sicura" sui segnali di feedback della latenza.
• Training data gaps. Le codebase più vecchie dominano i dati di training e sono antecedenti alle moderne impostazioni predefinite di sicurezza (rigorose CSP, SameSite=Lax, HSTS, RLS). Il codice generato riecheggia modelli che erano normali nel 2019 ma oggi non sicuri.
• Implicit platform trust. Quando Cursor genera un'app Vercel, presuppone che le impostazioni predefinite di Vercel siano sicure. Alcuni lo sono (auto-HTTPS, cookie firmati). Molti non lo sono (no CSP per impostazione predefinita, permissivi CORS, percorsi di debug predefiniti Next.js).

Dieci classi di vulnerabilità sovrarappresentate nelle app con codifica Vibe

In migliaia di scansioni di app AI-generate, le stesse classi di ricerca vengono visualizzate in modo sproporzionato:

1. Exposed Supabase service-role keys. Un service_role JWT (inizia eyJ) impegnato in un pacchetto client ignora ogni politica RLS sul progetto. Cursor lo completa automaticamente dalla parte sbagliata del confine; la chiave viene spedita in /_next/static/....
2. Missing Row-Level Security (RLS). Il modello vede CREATE TABLE public.items e procede senza abilitare RLS. Gli utenti anonimi possono quindi leggere o scrivere qualsiasi riga tramite la chiave anon pubblica. Vedere baas.supabase-rls.
3. Open Firebase / Firestore rules. I file delle regole generati spesso leggono allow read, write: if true; o saltano completamente il file delle regole. Le regole predefinite della modalità test scadono dopo 30 giorni e bloccano il database, ma solo se lo sviluppatore se ne accorge.
4. Hardcoded API keys in bundles. Stripe chiavi live, Anthropic sk-ant-*, OpenAI sk-*, Google AIza* e AWS AKIA* finiscono per essere incorporati nei payload JS quando la disciplina env-var scade. secrets.browser-storage li contrassegna a livello di pagina renderizzata.
5. Missing Content Security Policy. Nessuna intestazione di risposta Content-Security-Policy significa che ogni script in linea XSS è a un clic dal controllo completo dell'account. CSP è astratto; codegen lo salta regolarmente. headers.security-headers segnala il divario con le indicazioni sulle correzioni specifiche della piattaforma di distribuzione.
6. Next.js middleware misplacement. Con il layout src/, Next.js rileva solo src/middleware.ts: un middleware.ts a livello di root viene silenziosamente ignorato. L'autenticazione sembra ancora funzionare perché le pagine chiamano requireAuth(), ma le intestazioni, CSP e i limiti di velocità non arrivano.
7. IDOR via unsigned IDs. I gestori GET /api/items/[id] generati considerano attendibile il parametro del percorso e non verificano mai la proprietà. Se si percorre lo spazio intero o UUID vengono esposti i dati di ogni tenant.
8. Broken auth flows. Token Magic-link senza expires_at; JWT verifica che salta aud e exp; chiamate getSession() lato client (che leggono un cookie non verificato) anziché getUser() lato server.
9. Debug endpoints in production. Le rotte /api/debug, /api/health, /api/__nextjs_original-stack-frame o /.next/trace generate generano perdite interne. discovery.platform-vercel li analizza con la convalida del contenuto per evitare falsi positivi sui fallback SPA.
10. Plaintext sensitive fields. Password, chiavi API e PII archiviate come testo normale in Postgres perché la migrazione non ha raggiunto pgcrypto o un deposito esterno.

DAST vs SAST: perché entrambi sono importanti per il codice generato AI-

L'analisi statica (SAST) e l'analisi dinamica (DAST) sono complementari, non sostituti. La suddivisione è più importante per il codice AI-generato che per quello scritto a mano.

SAST legge il codice sorgente sul disco. Rileva segreti nei file sorgente, chiamate di funzioni pericolose e modelli rischiosi prima dell'esecuzione della compilazione. Non può vedere la configurazione di runtime, le variabili di ambiente distribuite o il modo in cui un bundler ha trasformato il tuo codice.

DAST colpisce l'applicazione distribuita come un utente. Vede le risposte inviate, viene eseguito rispetto al bundle di produzione e rileva la deriva della configurazione tra repository e distribuzione. Trova le chiavi hardcoded nel JavaScript transpilato che SAST non ha mai visto perché sono state immesse tramite un'assegnazione process.env in fase di creazione.

For AI-generated code, DAST is essential perché ciò che viene spedito differisce da ciò che ha scritto il modello. Il raggruppamento, lo scuotimento degli alberi, la traspilazione e l'inlining variabile dall'ambiente creano tutti nuove superfici. SAST nell'origine può perdere completamente i segreti incorporati nel bundle. DAST cattura entrambi i livelli. Una pipeline matura viene eseguita SAST in CI e DAST rispetto all'anteprima distribuita: questo è il modello FixVibe.

Cosa cercare in uno scanner di codici AI-

La maggior parte degli scanner DAST per uso generico (Burp Suite, OWASP ZAP, Nessus) sono stati progettati per app monolitiche e flussi di autenticazione tradizionali. La scansione di un'app generata Vercel + Supabase + Stripe AI- richiede:

• BaaS coverage. Verifiche reali rispetto a Supabase RLS, Firebase / regole Firestore, configurazione Clerk, AWS Amplify e le forme JWT emesse da tali servizi. Le regole generiche OWASP non sanno cosa contrassegnare.
• JS bundle inspection. Regex ottimizzato per formati chiave API-, token firmati e modelli specifici del provider (Stripe sk_live_, Anthropic sk-ant-, Supabase JWT a partire da eyJ). L’euristica entropica generica genera troppi falsi positivi.
• Passive + active split. I controlli passivi (intestazioni, cookie, segreti, configurazione BaaS, DNS) vengono eseguiti in modo sicuro contro qualsiasi URL. Le sonde attive (SQLi, XSS, SSTI, IDOR camminando) richiedono un limite di autorizzazione perché sparano payload in stile attacco.
• Framework awareness. Riconoscimento del router per app Next.js rispetto al router delle pagine, riscritture di Vite SPA, protezione della distribuzione Cloudflare, routing delle pagine. Uno scanner che non distingue un Vite SPA fallback da un vero /_next/build-manifest.json genera rumore.
• Rate-limit safety. Budget di richiesta limitati per scansione, confronto tra risposte di base per evitare WAF-falsi positivi confusi, linee di base di sondaggi del percorso randomizzati per rilevare distribuzioni coperte-403.
• Authorization gating for intrusive payloads. L'invio di payload di comandi SQLi o OS- a un dominio che non possiedi è illegale nella maggior parte delle giurisdizioni. Uno scanner reale richiede la verifica della proprietà del file DNS o HTTP- prima di consentire l'esecuzione della modalità attiva su una destinazione.

L'approccio di FixVibe: scansione basata sull'evidenza, basso numero di falsi positivi

FixVibe is a DAST built specifically for AI-generated web apps. The passive phase runs 200+ checks on the rendered page (headers, CSP, cookies, leaked secrets, BaaS misconfiguration, tech fingerprinting, DNS, attack-surface discovery). The active phase adds payload-firing probes (SQLi, XSS, SSTI, CORS, redirects, IDOR walking, CSRF, account enumeration, blind-SSRF) gated behind verified-domain ownership. Repo scans add code-phase checks against connected GitHub repositories. Every finding includes evidence, a CWE link, a remediation recipe, and either a coding-agent prompt or operator steps depending on who can actually apply the fix. The scan engine is open in the changelog — every new check, accuracy improvement, and false-positive fix is logged publicly.

FixVibe vs Burp Suite, ZAP e Nessus: quando ogni strumento vince

Nessun singolo strumento copre ogni flusso di lavoro. L'onesto inquadramento di dove si inserisce FixVibe:

Dove gli strumenti si completano a vicenda

• Start with FixVibe passive come riferimento gratuito di 30 secondi rispetto a qualsiasi anteprima di distribuzione. Se non emerge nulla, hai un segnale di fiducia veloce.
• Move to FixVibe active su un dominio verificato quando desideri una copertura attiva completa (SQLi/SSTI/IDOR/etc.) contro la tua infrastruttura.
• Layer SAST (Semgrep, CodeQL, Snyk) sul codice sorgente in CI. SAST rileva ciò che il runtime non può vedere: modelli rischiosi nei percorsi del codice che non raggiungono mai la distribuzione.
• Reach for Burp Suite quando sono necessarie catene di attacco personalizzate (bypass di autenticazione specifici, scenari IDOR complessi, difetti di logica aziendale). Burp è il banco da lavoro manuale più profondo disponibile; FixVibe è la linea di base automatizzata più veloce.

Prossimi passi

Continue con Vibe coding security checklist per un audit pre-spedizione di 44 elementi oppure passa a How to secure an app built with AI coding tools per un rafforzamento passo passo con snippet di codice.