L’applicazione è stata fatta con Lovable, Bolt, Replit, Cursor o simili: potete testarla?

Sì. Lo strumento con cui è stata costruita non conta: testiamo l’applicazione pubblicata e, se ce lo date, il codice. Conosciamo i problemi tipici di ciascuna di queste piattaforme.

Non abbiamo uno sviluppatore interno: come correggiamo i problemi?

Il report è scritto per essere usato: per ogni problema indichiamo cosa correggere e come. Le indicazioni si possono passare a un freelance o incollare direttamente nell’assistente AI che ha generato il codice. Se serve, vi affianchiamo nella verifica delle correzioni.

Serve un test completo o basta una verifica rapida?

Dipende da cosa gestisce l’applicazione. Se raccoglie dati personali, pagamenti o dati aziendali, serve un test completo prima di andare online. Per un prototipo interno può bastare una verifica mirata dei punti critici: lo valutiamo insieme.

Per un’applicazione di dimensioni contenute, in genere 5-10 giorni lavorativi tra code review e penetration test.

Sicurezza delle applicazioni sviluppate con l’AI (vibe coding)

Avete costruito un’applicazione con Cursor, Lovable, Bolt, Replit o un altro assistente AI? Prima di metterla online, o di continuare a usarla, verifichiamo che non esponga dati, chiavi e funzioni.

Il vibe coding permette a sviluppatori, startup e aziende di creare applicazioni in giorni invece che in mesi. Il codice generato dall’AI funziona, ma la sicurezza viene quasi sempre trascurata: chiavi nel frontend, database aperti, controlli di accesso che esistono solo nell’interfaccia. Facciamo code review e penetration test proprio su queste applicazioni.

I problemi che troviamo più spesso

Chiavi e segreti nel codice

Chiavi API, password di database e token inseriti direttamente nel codice o nel frontend, dove chiunque può leggerli.

Autorizzazioni mancanti

Il controllo è solo nell’interfaccia: cambiando un identificativo nell’indirizzo si vedono i dati di altri utenti, o si eseguono operazioni da amministratore.

Database esposti

Regole di accesso assenti o troppo permissive su Supabase, Firebase e servizi simili: il database è leggibile e scrivibile da chiunque conosca l’indirizzo.

API senza controlli

Endpoint generati dall’AI senza validazione degli input, senza autenticazione o con CORS aperti a tutti.

Dipendenze a caso

Librerie vecchie, vulnerabili o inventate, aggiunte perché “funzionava”, senza nessuno che le abbia verificate.

Nessun limite

Niente rate limiting, niente protezione dagli abusi: un’applicazione che si può bloccare, o far costare cara, con uno script di poche righe.

Nessuno di questi problemi si vede usando l’applicazione: funziona tutto. Si vedono solo guardando il codice e provando ad attaccarla.

Per chi è

Startup e founder che hanno costruito il prodotto con l’AI e devono presentarlo a clienti o investitori.

Sviluppatori e software house che usano assistenti AI e vogliono una verifica indipendente prima del rilascio.

Aziende in cui un reparto ha creato da sé un’applicazione interna, un portale o un’automazione che tratta dati aziendali.

Come si svolge

1
Analisi
Guardiamo come è fatta l’applicazione: stack, servizi usati, come è pubblicata, dove stanno i dati e chi può accedervi.
2
Code review mirata
Leggiamo il codice nei punti che contano: autenticazione, autorizzazioni, gestione dei segreti, accesso ai dati, integrazioni esterne.
3
Penetration test
Testiamo l’applicazione dall’esterno come farebbe un attaccante, con la metodologia OWASP, per confermare quali problemi sono davvero sfruttabili.
4
Report e correzioni
Consegniamo un report chiaro, con priorità e indicazioni concrete che potete dare direttamente al vostro sviluppatore o al vostro assistente AI.

Se l’applicazione integra un chatbot o un modello linguistico, estendiamo il test alla parte AI: vedi penetration test di applicazioni AI, chatbot e LLM.

Cosa ricevete

Il report con i problemi trovati, classificati per criticità, e le evidenze.
Per ogni problema, cosa correggere e come, in forma utilizzabile anche da chi non è uno specialista.
Una checklist di sicurezza per i prossimi sviluppi con l’AI.
Il supporto nella verifica delle correzioni.

Perché Ancharia

Laboratorio Accreditato di Prova iscritto nell’elenco ufficiale ACN ai sensi del DPCM 18 maggio 2022, n. 92.

Metodologie OWASP e NIST, le stesse dei penetration test per le grandi aziende, dimensionate su applicazioni piccole e veloci.

Facciamo source code review, threat modeling e security design review: sappiamo leggere il codice, non solo attaccarlo.

Report chiari, senza gergo, pensati per chi deve decidere e per chi deve correggere.

Domande frequenti

È il modo di sviluppare in cui si descrive all’AI cosa si vuole e si accetta il codice generato, iterando finché funziona. Permette di costruire applicazioni in pochissimo tempo, ma la sicurezza non è mai in cima alle priorità dell’assistente: il risultato funziona, ma spesso espone dati, chiavi e funzioni.

Approfondimenti

AI e LLM

Prompt injection: cos’è e come proteggere il vostro chatbot

Cos’è la prompt injection, diretta e indiretta, perché è il rischio numero uno delle applicazioni con LLM e quali contromisure funzionano davvero.

4 min di letturaLeggi

AI e LLM

Vibe coding: i 6 errori di sicurezza più comuni

Chiavi esposte, database aperti, autorizzazioni solo nell’interfaccia: i problemi di sicurezza che troviamo più spesso nelle applicazioni sviluppate con l’AI.