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

The same finding classes show up disproportionately in AI-generated apps:

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 Supabase Row-Level Security.
3. Open Firebase / Firestore rules. Generated rules files often read allow read, write: if true; or skip the rules file entirely. Test-mode rules let anyone read and overwrite data until someone replaces them.
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 in JavaScript Bundles 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. HTTP 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. Generated /api/debug, /api/health, /api/__nextjs_original-stack-frame, or /.next/trace routes leak internals. FixVibe reports them only with evidence that they really are exposed (Vercel-Specific Exposure).
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. Recognising real API-key formats — Stripe sk_live_, Anthropic sk-ant-, Supabase service-role keys — and telling a secret key from a publishable one. Generic pattern matching throws too many false positives.
• 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. Recognising Next.js App Router vs Pages Router, Vite SPA rewrites, Vercel deployment-protection, Cloudflare Pages routing. A scanner that doesn't understand how these platforms answer unknown paths generates noise.
• Rate-limit safety. Bounded request budgets per scan, and findings that require positive evidence — a blanket 403 from a WAF is not proof a file exists.
• 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 230+ 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

No single tool covers every workflow. For a sourced side-by-side of FixVibe, Burp Suite, ZAP, Snyk, Semgrep and Aikido, with a decision matrix, see choosing a security scanner for AI-built apps.

Dove gli strumenti si completano a vicenda

• Start with FixVibe passive as a free baseline against any deploy preview — it usually finishes in under a minute. If nothing surfaces, you have a fast confidence signal.
• 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 51 elementi oppure passa a How to secure an app built with AI coding tools per un rafforzamento passo passo con snippet di codice.