1. API key incorporate nel JavaScript del tuo frontend
È l'errore più dannoso e il più facile da commettere. Chiedi al tuo strumento di AI di "aggiungere i pagamenti Stripe" o di "collegarsi a OpenAI" e lui inserisce la chiave segreta direttamente in un componente client. L'app funziona — e la tua chiave segreta ora arriva al browser di ogni visitatore, leggibile da chiunque apra i DevTools o analizzi il tuo bundle JS.
Tutto ciò che ha il prefisso NEXT_PUBLIC_ (o VITE_, o REACT_APP_) viene incorporato nel bundle client in fase di build. Le chiavi segrete — sk_live_ di Stripe, sk- di OpenAI, URL di database, chiavi service role — devono essere lette esclusivamente nel codice lato server: API route, componenti server o funzioni edge.
Il controllo rapido: apri il tuo sito in produzione, visualizza il sorgente della pagina e il JS raggruppato e cerca sk_live, sk- e i primi caratteri delle chiavi nel tuo .env. Se ne compare qualcuna, ruota prima la chiave, poi sposta la chiamata lato server.
2. .env o .git serviti direttamente dalla tua web root
Un numero sorprendente di app in produzione restituisce tranquillamente il proprio file .env — o l'intera directory .git — se basta chiederlo. È sufficiente un server di file statici mal configurato o un template di framework che copia tutto nella cartella pubblica.
L'impatto è totale: credenziali del database, secret di autenticazione, API key, tutto in un unico file. Una directory .git esposta è quasi altrettanto grave, perché un malintenzionato può ricostruire l'intera cronologia del codice, inclusi i secret che sono stati committati e poi "rimossi".
Il controllo rapido richiede dieci secondi:
curl -i https://yourapp.com/.env
curl -i https://yourapp.com/.git/config
# Both should return 404 (or 403) — never 200.3. Nessuna Content-Security-Policy
Gli strumenti di AI non aggiungono quasi mai gli header di sicurezza, e la CSP è quello che conta di più. Senza di essa, un solo bug di HTML injection o XSS in un punto qualsiasi della tua app permette a un malintenzionato di eseguire JavaScript arbitrario nei browser dei tuoi utenti: rubare sessioni ed esfiltrare dati.
Una buona policy iniziale per la maggior parte delle app: default-src 'self', blocca oggetti e incorniciamento e consenti solo le origini di script di terze parti che usi davvero. Parti rigoroso, allenta con intenzione — mai il contrario.
// next.config.js
const csp = [
"default-src 'self'",
"script-src 'self'",
"style-src 'self' 'unsafe-inline'",
"img-src 'self' data:",
"base-uri 'none'",
"frame-ancestors 'none'",
"object-src 'none'",
].join("; ");
module.exports = {
async headers() {
return [{ source: "/:path*", headers: [{ key: "Content-Security-Policy", value: csp }] }];
},
};4. Cookie di sessione senza Secure, HttpOnly e SameSite
Se la tua libreria di autenticazione è stata collegata da uno strumento di AI con le opzioni predefinite, vale la pena verificare i flag del cookie di sessione. Un cookie senza HttpOnly può essere letto da qualsiasi script iniettato (trasformando un piccolo XSS in una presa di controllo completa dell'account), uno senza Secure può trapelare su HTTP in chiaro e uno senza SameSite rende molto più facile la cross-site request forgery.
Apri DevTools → Application → Cookies sulla tua app in produzione. Ogni cookie di sessione o di autenticazione dovrebbe mostrare tutti e tre: Secure, HttpOnly e SameSite=Lax (o Strict).
5. HTTP che non diventa mai HTTPS (e nessun HSTS)
La maggior parte delle piattaforme di hosting ti dà HTTPS automaticamente — ma molte app continuano a rispondere tranquillamente su HTTP in chiaro senza reindirizzare, oppure reindirizzano ma non inviano mai un header Strict-Transport-Security. In entrambi i casi, un utente che digita il tuo dominio nella barra degli indirizzi effettua la sua prima richiesta non cifrata, e quella richiesta può essere intercettata o declassata prima che avvenga il tuo redirect.
La soluzione sono due righe di configurazione: un redirect permanente 301 da HTTP a HTTPS, più un header HSTS (max-age=31536000; includeSubDomains) così che i browser si rifiutino di declassare la connessione mai più.
6. CORS impostato per consentire tutto
Quando un frontend generato con l'AI non riesce a raggiungere la propria API durante lo sviluppo, la "soluzione" che viene generata è quasi sempre Access-Control-Allow-Origin: * — a volte con anche le credenziali consentite. Questo dice a ogni sito web su internet che può chiamare la tua API dai browser dei suoi visitatori.
Per un'API che serve il tuo frontend, l'origine consentita dovrebbe essere esattamente il tuo dominio, e nient'altro. Il CORS con wildcard è accettabile solo per API davvero pubbliche, senza autenticazione e in sola lettura.
7. Nessun SPF o DMARC sul tuo dominio
Questo non riguarda affatto il codice della tua app — riguarda il tuo dominio. Senza i record DNS SPF e DMARC, chiunque può inviare email che affermano di provenire da [email protected], e i server di posta riceventi non hanno modo di sapere che sono contraffatte. È phishing contro i tuoi stessi utenti, con addosso il tuo brand.
Due record DNS TXT risolvono il problema. Se invii email tramite un provider come Resend, Postmark o SES, la loro documentazione ti fornisce il valore SPF esatto; aggiungi una policy DMARC accanto e stringila da p=none a p=quarantine una volta confermato che la posta legittima supera i controlli.
Controllali tutti e sette in una sola volta
Ogni voce di questo elenco è rilevabile dall'esterno, il che significa che non devi passarla in rassegna a mano. AppSafe esegue tutti questi controlli — più SSL/TLS, subdomain takeover, source map e altro — in un'unica scansione, valuta il risultato con un voto da A a F e ti dà un prompt di correzione AI per ogni problema, da incollare direttamente in Cursor o Claude Code.
La scansione rapida sulla homepage non richiede registrazione. La scansione completa (inclusi i controlli sui secret esposti) viene eseguita solo sui domini di cui hai verificato la proprietà — per scelta progettuale, dato che non analizzeremo i bundle JS di qualcun altro alla ricerca di chiavi.