Perché i tool di coding AI lasciano falle di sicurezza

Perché AI-il codice generato differisce in termini di sicurezza

AI Gli strumenti di codifica hanno ragioni strutturali per le lacune di sicurezza che creano. Non sono sviste casuali; sono artefatti prevedibili di formazione e ottimizzazione.

• Training data skews toward "make it work." Repository open source ed esercitazioni dominano la formazione LLM. Il repository mediano OSS è stato scritto per risolvere un problema, non per essere un esempio di rafforzamento della sicurezza. Un LLM impara la distribuzione del codice in natura, non la distribuzione del codice sicuro.
• Autocomplete is sticky. Quando incolli uno snippet di codice che utilizza una chiave service_role, diventa il modello per il file successivo. Il completamento automatico di Cursor lo suggerirà in un componente client a cui non è mai appartenuto. Lo strumento fa ciò per cui è stato ottimizzato (velocità), ma non è a conoscenza del limite di sicurezza.
• No long-term context or incident memory. Uno sviluppatore umano che ha bruciato un database di produzione con una clausola WHERE mancante porta avanti quella lezione per anni. Un LLM non ha memoria episodica. Ogni file è un nuovo inizio. Lo strumento non apprende dal tuo ultimo RLS bypass o dall'incidente post-mortem del tuo team.
• Speed is the rewarded metric. Gli sviluppatori scelgono questi strumenti perché vengono spediti velocemente. Il feedback sulla latenza è immediato e diretto. Il feedback sulla sicurezza è assente o ritardato: una vulnerabilità rilevata in una scansione FixVibe tre settimane dopo la spedizione. Il LLM è stato ottimizzato per la metrica umana premiata in tempo reale.
• Implicit trust in platform defaults. Quando Cursor genera un'app Vercel, presuppone che le impostazioni predefinite di Vercel siano rafforzate. Alcuni sono: auto-HTTPS, cookie firmati, protezione DDoS. Altri non lo sono: no CSP per impostazione predefinita, no HSTS, permissivo CORS. Il codice generato eredita presupposti della piattaforma che non sono sempre giustificati.

Lacuna 1: segreti nei bundle client

Le chiavi API del ruolo di servizio, i token OAuth e le chiavi private finiscono nei bundle JavaScript forniti al browser. FixVibe li contrassegna come risultati secrets.browser-storage e secrets.bundle-leak. Le chiavi sono rilevabili nelle mappe sorgente, nel codice minimizzato o nel testo normale JS.

Why it happens: Cursor incollare uno snippet Supabase che inizializza un client con il ruolo del servizio significa che il codice è ora nel completamento automatico. Un componente React generato richiede "ottieni tutti gli elementi dal database" e Cursor suggerisce l'importazione del client di servizio. Il confine tra codice solo server e lato client è astratto per LLM.

Fix: Memorizza i segreti nelle variabili di ambiente contrassegnate NEXT_PUBLIC_ solo per le chiavi pubbliche. Le chiavi di servizio, le chiavi private API e i segreti di firma devono vivere in src/lib/secrets.ts con import 'server-only'. Utilizza azioni server o percorsi API per chiamare servizi sensibili, mai componenti client.

Gap 2: sicurezza a livello di riga mancante o incompleta

Le tabelle Supabase vengono create senza RLS abilitato. Firebase Le regole di Firestore non vengono mai scritte o lasciate in modalità test permissiva. Gli utenti Anon possono leggere e scrivere ogni riga. FixVibe segnala questo come baas.supabase-rls e baas.firebase-rules.

Why it happens: RLS è una funzionalità specifica di Postgres. Gli LLM formati su Rails, Django, Laravel ed Express considerano i controlli di autenticazione a livello di applicazione come la norma. L'abilitazione di RLS su Supabase richiede istruzioni ALTER TABLE esplicite e definizioni di policy: modelli meno comuni nei dati di training.

Fix: Per Supabase, applicare RLS con ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY; su ogni tavolo. Crea policy che limitino le righe all'utente o all'organizzazione autenticata. Per Firebase, non lasciare mai le regole come modalità di test predefinita; scrivere regole esplicite con ambito all'utente autenticato.

Gap 3: confusione sui confini di autenticazione

Le sessioni vengono convalidate lato client utilizzando getSession() (che legge un cookie non verificato). I collegamenti magici non hanno scadenza. JWTs salta i controlli aud e exp. Le reimpostazioni della password sono reversibili. FixVibe li contrassegna come risultati active.auth-flow.

Why it happens: Supabase Auth, Clerk e servizi simili gestiscono lo stato della sessione, ma i loro API hanno modalità sicure e non sicure. getSession() è conveniente ma non verificato. Il LLM vede la comodità API più spesso che la sicurezza nei dati di addestramento. La convalida del token lato server è astratta e richiede intestazioni HTTP esplicite o invocazione del middleware.

Fix: Utilizza sempre supabase.auth.getUser() lato server. Non fidarsi mai di getSession() sui percorsi protetti. Convalida JWT su ogni richiesta, controllando exp, aud e firma. Imposta la scadenza del token su 1 ora per i token di accesso e utilizza i token di aggiornamento per sessioni più lunghe.

Lacuna 4: intestazioni di sicurezza HTTP mancanti

No Content-Security-Policy, no X-Frame-Options, no Strict-Transport-Security, no X-Content-Type-Options. FixVibe segnala questo come risultati headers.security-headers.

Why it happens: Le intestazioni di sicurezza sono specifiche della piattaforma di distribuzione. Cursor genera il codice per Next.js; l'impostazione CSP richiede una modifica next.config.js, un middleware o una sostituzione vercel.json. Questi non sono negli scaffold di progetto predefiniti. Il modello mentale secondo cui "le intestazioni sono per DevOps" è ancora comune.

Fix: Set CSP in next.config.js or middleware with nonce support: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; .... Add HSTS: Strict-Transport-Security: max-age=31536000; includeSubDomains. Use Vercel's vercel.json headers or middleware for static hosts.

Gap 5: configurazioni errate di integrazione di terze parti

Le chiavi Stripe, i token Sentry e le chiavi Anthropic API sono codificate o impegnate nei repository. Le origini di Analytics sono eccessivamente permissive. le dipendenze npm sono obsolete. Le scansioni FixVibe li contrassegnano come risultati in discovery.tech-fingerprint e nei nostri controllori segreti.

Why it happens: Le integrazioni vengono incollate dalla documentazione e dai tutorial. LLM copia il modello, inclusi eventuali valori codificati. La disciplina Env-var richiede una disciplina esplicita in CI/CD, che LLM non può applicare.

Fix: Utilizza variabili di ambiente per ogni credenziale di terze parti. Archivia i segreti nella tua piattaforma di distribuzione (Vercel, Netlify, Heroku o un vault). Controlla le dipendenze npm con npm audit mensilmente. Utilizza Dependabot o Renovate per PR automatizzate quando sono disponibili aggiornamenti di sicurezza.

Il modello di riparazione

Per colmare queste lacune non è necessario ricostruire da zero. Lo schema è coerente:

1. Audit: Esegui FixVibe contro la tua app live. Per le scansioni repository, abilitare l'app FixVibe GitHub. Raccogli i risultati: segreti, RLS, autenticazione, intestazioni, terze parti.
2. Rinforza: Risolvi i risultati ad alta confidenza. Abilita RLS + FORCE. Sposta i segreti nelle variabili d'ambiente. Imposta CSP e HSTS nel middleware. Usa la validazione auth lato server. Usa il prompt per l'agente di codice solo dove si applicano modifiche a codice/configurazione, e segui i passaggi operatore per DNS o correzioni gestite dal provider.
3. Monitor: Pianifica scansioni passive giornaliere o scansioni attive settimanali su un dominio verificato. Configura i webhook su Slack. Ogni risultato critico dovrebbe far scattare un allarme entro pochi minuti dalla nave.
4. Rispondi: Quando emerge un risultato, copia l'azione di remediation FixVibe corrispondente al responsabile del fix: un prompt per agente di codice per lavori su codice/configurazione, oppure passaggi operatore per DNS, console provider, rotazione segreti e revisione manuale. Riavvia la scansione per confermare.

Dove va il campo

Risolvere queste lacune oggi è compito dei team. Nei prossimi 2-3 anni, la frontiera si sposterà: migliori impostazioni predefinite in framework e strumenti (Next.js middleware auto-CSP, Supabase RLS come impostazione predefinita), feedback sulla sicurezza IDE-time (Cursor suggerimenti che avvisano quando stai per incollare una chiave di servizio in un componente client) e correzione automatica MCP-driven (l'agente di codifica ha accesso ai risultati FixVibe e può risolverli autonomamente). Il pubblico di FixVibe changelog traccia per primi quali lacune si stanno colmando.

Prossimi passi

Per l'elenco di controllo go/no-go prima del lancio, vedere Pre-launch SaaS security checklist. Per una procedura dettagliata sul rafforzamento con frammenti di codice e modelli di errore reali, leggere How to secure an app built with AI coding tools.