Capstone — hardening: sicurezza, privacy, deploy

Capstone funziona localmente. Adesso il salto: pubblicabile. Significa applicare le lezioni 53-59 al tuo progetto specifico. Sicurezza, privacy, deploy, monitoring. Niente di tutto questo è “extra”: è ciò che separa un demo da qualcosa di mostrabile con responsabilità.

Perché questa lezione conta

Mostrare un prototipo non hardened è duplice rischio: tecnico (vulnerabilità) e reputazionale (bug evidenti, errori 500, leak di dati). Investire 90 minuti nell’hardening converte “funziona sul mio computer” in “posso condividere con orgoglio”. Il capstone è il primo progetto dove applichi la disciplina; futuri progetti la useranno per default.

Obiettivo operativo

Alla fine della sessione devi avere:

1. audit sicurezza completato (segreti, OWASP minimo);
2. privacy policy se applicabile (GDPR);
3. pre-deploy checklist eseguita;
4. capstone deployato in produzione (anche solo accessibile a te);
5. piano monitoring + rollback.

Nucleo della lezione

1. Audit sicurezza

Esegui in ordine:

Segreti (lezione 53):

• nessun .env in repo (git log --all --full-history -- .env* deve essere vuoto);
• .env.example aggiornato;
• chiavi produzione in pannello hosting, non locale;
• pre-commit hook gitleaks (consigliato).

OWASP minimo (lezione 57):

• npm audit no high/critical;
• security headers (HSTS, CSP base, X-Frame-Options);
• HTTPS forzato;
• niente segreti nel bundle client (grep -r 'sk_' dist/ deve essere vuoto);
• error messages generici per 500 esterni.

Permessi/validazione (lezione 55):

• ogni endpoint ha auth + authz + validazione;
• niente mass assignment;
• niente IDOR.

Per capstone semplice (single-user, niente backend, dati locali) la maggior parte di questi è trivialmente OK. Per capstone con backend/multi-utente, ognuno è bloccante.

2. Privacy

Anche per capstone personale, considera:

• raccogli dati personali? (anche solo email tua, IP)
• usa servizi terzi che ricevono dati? (Vercel, Supabase, hosting)
• il GDPR si applica anche a piccolo progetto;

Per capstone:

• privacy policy minima (template OK come punto di partenza, ma personalizza);
• cookie banner se carichi analytics o cookie non strettamente tecnici;
• export/cancellazione utente se memorizzi dati sul server;
• DPA con fornitori (anche se solo Vercel: revisiona ToS).

Per capstone local-first (es. tracker abitudini con IndexedDB only): privacy policy MOLTO più semplice perché niente lascia dispositivo. Ma manifest dati va comunque comunicato all’utente.

3. Deploy

Per piattaforme tipiche (Vercel, Netlify, Fly):

• collega repo;
• configura env produzione;
• domain custom (se hai) con DNS configurato;
• verifica build CI passa;
• deploy.

Smoke test produzione (lezione 58):

• pagina principale carica;
• flusso principale funziona end-to-end;
• console no errori;
• network: solo chiamate attese, niente leak;
• Lighthouse score Performance/Accessibility/Best Practices > 80.

Per capstone privato (solo tu): deploy su URL nascosta o staging only. Per capstone pubblico: comunicalo, accetta feedback.

4. Monitoring + rollback

Anche per piccolo progetto:

• Uptime check: BetterUptime o Cronitor (free tier sufficienti);
• Error logging: Sentry free tier;
• Analytics privacy-friendly: Plausible, Umami, o niente analytics se davvero non servono.

Procedura rollback documentata in docs/incident.md:

• come fare rollback su Vercel/Netlify (1 click);
• come ruotare segreti se compromessi;
• chi contattare in caso (se hai team o cliente).

Hardening guidato

Prima del deploy, dividi i controlli in tre livelli.

Bloccanti:

• segreti nel client o nella repo;
• endpoint senza autorizzazione;
• dati personali non necessari;
• build fallita;
• errore console nel flusso principale;
• perdita o cancellazione dati senza conferma.

Da correggere prima della demo pubblica:

• messaggi errore generici;
• loading assente;
• mobile rotto;
• dipendenze con warning critici;
• log troppo rumorosi o con dati personali.

Da documentare se non correggi subito:

• limiti noti;
• funzionalità manuali;
• mancanza sync;
• browser non supportati;
• assenza backup automatico.

Esempio decisione:

Deploy pubblico bloccato: il report Network mostra email utente nei log client.
Deploy demo privata consentito solo dopo rimozione log e rotazione dati demo.
Nota release: progetto local-first, nessun sync multi-dispositivo nella v1.

Hardening non significa rendere perfetto. Significa sapere cosa è abbastanza sicuro da mostrare, cosa è rischioso e cosa va dichiarato.

Procedura pratica

90 minuti:

1. Audit sicurezza (25 min): segreti + OWASP + permessi.
2. Privacy (15 min): policy + cookie + export.
3. Pre-deploy checklist (15 min): esegui voci della lezione 58.
4. Deploy (15 min): collega, configura, deploya.
5. Smoke test produzione (10 min): verifica + Lighthouse.
6. Monitoring setup (10 min): uptime + Sentry.

Laboratorio guidato

Per il capstone “tracker abitudini” local-first:

Sicurezza:

• segreti: niente API key (no backend). .env.example può essere vuoto.
• OWASP: app statica, attack surface minimal. CSP default-src 'self'. HTTPS forzato (Vercel default).
• audit dipendenze: bun audit (o equivalente).

Privacy:

• pagina /privacy.html con: “Questa app salva i tuoi dati solo nel tuo browser (IndexedDB). Niente dati lascia il dispositivo. Niente analytics. Hosting: Vercel (USA), serve solo file statici.”
• niente cookie banner perché niente cookie tracking.
• export utente: bottone “Esporta dati” che genera CSV/JSON da IndexedDB e fa download.
• cancellazione: bottone “Cancella tutti i dati” + conferma.

Pre-deploy checklist:

• build pulita ✓
• typecheck ✓
• test pass ✓
• console.log random ✗ (rimuovi)
• env produzione: nessuna richiesta
• Lighthouse mobile: target 90+

Deploy:

• vercel --prod o equivalente.
• domain personalizzato (opzionale, capstone privato OK con *.vercel.app).

Smoke test:

• apri URL produzione su iPhone reale;
• aggiungi 1 abitudine, toggle, verifica persistenza dopo refresh;
• Lighthouse run.

Monitoring:

• uptime check su URL principale (BetterUptime free).
• Sentry frontend (free tier basta).

90 minuti, deploy fatto, capstone reale visibile.

Output atteso

Capstone in produzione con:

• audit sicurezza completato e documentato;
• privacy policy presente;
• pre-deploy checklist eseguita;
• deploy verificato con smoke test;
• monitoring base attivo;
• piano rollback documentato.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: portare il prototipo al punto in cui può essere mostrato con responsabilità, non solo ‘funzionare sul mio computer’. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Controllo segreti, env, dipendenze, permessi, validazione server, dati personali e logging.
• Preparazione deploy: build, variabili, dominio, fallback, monitoraggio minimo, rollback.
• Decisione finale: pubblico, demo privata, video, repository chiusa o ulteriore lavoro prima del rilascio.

3. Applicazione: svolgi il laboratorio: applicare checklist sicurezza/pre-deploy al capstone e correggere le voci critiche. L’output da ottenere è: una build candidata al rilascio con note su sicurezza, privacy e limiti dichiarati.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• ho fatto audit segreti del capstone;
• privacy policy presente (anche minima);
• pre-deploy checklist eseguita prima del deploy;
• capstone deployato e accessibile;
• smoke test produzione fatto;
• uptime monitor + error tracking attivi;
• procedura rollback documentata.

Errori comuni

“Skip security, è capstone privato”. Anche capstone privato può essere indicizzato, condiviso accidentalmente, scoperto via subdomain enumeration. Disciplina anche per privato.

Niente privacy policy. Anche app local-first dovrebbe spiegare cosa fa con i dati. Trasparenza minima.

Deploy senza checklist. Bug evidenti in produzione, frustrazione.

Niente smoke test post-deploy. Hai pushato, non sai se funziona.

Niente monitoring. Errori scoperti dagli utenti, non da te. Free tier basta.

Niente piano rollback. Quando rompi, panico.

Prompt di lavoro

Audit hardening per il mio capstone.

Brief: [link]
Stack: [...]
Hosting target: [Vercel / Netlify / ...]
Tipo dati: [local-first / server / misto]
Pubblicità: [solo me / piccolo cerchio / pubblico]

Per ognuna delle 4 aree:

1. Sicurezza: segreti, OWASP minimo applicabile al mio caso, permessi.
2. Privacy: minimo da fare per il mio tipo di app + privacy policy template.
3. Pre-deploy: checklist eseguibile in 10 min.
4. Deploy + monitoring: comandi specifici per la mia piattaforma + setup monitor minimal.

Output: lista azionabile di task, prioritizzati, con comandi/snippet pronti.

NON fare deploy ancora. Voglio prima validare il piano.

Esercizio finale

Esegui hardening completo. Misura: tempo speso, problemi trovati, problemi sistemati prima del deploy. Il capstone hardened è la dimostrazione concreta che hai assorbito il corso. Diventa portfolio personale.