Sicurezza
Ultimo aggiornamento: 30 aprile 2026
Claudio Code ti dà accesso al tuo terminale Claude Code da telefono. Significa che la responsabilità di sicurezza è massima · ogni decisione tecnica passa dal filtro «questo regge se quello che gira è critico?». Qui spieghiamo cosa garantiamo e come.
Il tuo terminale non è mai pubblico
La sessione tmux che gira sul tuo Mac (o Windows · supporto in arrivo) è raggiungibile solo dal token che hai generato tu nel tuo account. Ogni richiesta passa attraverso un proxy WebSocket che verifica il token e indirizza al singolo utente · non c'è un endpoint pubblico che esponga l'output del terminale di nessuno.
Il bridge usa Cloudflare Tunnel (named tunnel), non un ngrok aperto. Il tunnel è autenticato, ha un nome univoco e non viene indicizzato.
Le sessioni di lavoro non sono visibili agli altri
Ogni utente vive in un tenant isolato. La dashboard, le memorie, i token bridge, le sessioni Claude Code, i log di consumo API · ogni risorsa è legata al tuo user_id a livello di query SQL. Non esiste una vista «tutte le sessioni» o «tutti gli utenti» accessibile dal client.
A livello backend usiamo PostgreSQL con Row Level Security policies sulle tabelle account-scoped: ogni request settaapp.account_id dal middleware e il database rifiuta query che attraversano tenant. Doppia protezione: applicativa + database.
Token bridge: usa-e-rinnova, scadenza, revoca
Quando crei un token bridge dal tuo account, vedi il valore una sola volta · non lo conserviamo in chiaro, ma come hash. Il token è legato al tuo user_id e può essere revocato in qualsiasi momento dalla pagina Impostazioni.
Se il tuo Mac viene compromesso, basta revocare il token per disconnetterlo. Non serve cambiare password: il token bridge è un canale separato.
Cookie httpOnly Secure SameSite
Il cookie di sessione è __Host-cc-session. Il prefisso__Host- impone tre vincoli al browser: Path=/,Secure obbligatorio (solo HTTPS), nessun attributo Domain · cioè il cookie è bound al dominio esatto. ÈHttpOnly (il JavaScript della pagina non può leggerlo) e SameSite=Lax (il browser non lo invia in richieste cross-site).
La sessione è un JWT firmato HS256 con scope="cc". Anche se qualcuno copiasse un cookie di Studios non potrebbe usarlo qui.
Rate limit + audit log immutabile
Gli endpoint sensibili (signup, login, forgot password, resend verify) hanno rate limit per IP e per email. Login: max 10 tentativi per IP / 5 per email ogni 5 minuti. Signup: 5 per IP ogni 10 minuti.
Ogni operazione critica scrive su claude_os_audit_log: chi ha fatto cosa, quando, da quale IP, con quale user-agent. La tabella è append-only (nessun endpoint applicativo permette di cancellare righe). Backup giornalieri della stessa.
Security headers strict
Tutte le pagine servono questi header HTTP:
Strict-Transport-Security: max-age 2 anni · includeSubDomains · preloadContent-Security-Policy:default-src 'self'+ allowlist puntualiX-Frame-Options: SAMEORIGIN · niente embed in iframe esterniX-Content-Type-Options: nosniffReferrer-Policy: strict-origin-when-cross-originPermissions-Policy: camera/microphone/geolocation/FLoC tutti disabilitatiCross-Origin-Opener-Policy: same-originCross-Origin-Resource-Policy: same-site
HTTPS-only: redirect 301 da HTTP. HSTS preload list submission in coda.
Sanitizzazione input audio (voice refine)
Quando usi la voice-to-text per inviare comandi al Mac, il flusso è: 1) registriamo audio nel browser (mai conservato server-side oltre la singola richiesta), 2) lo passiamo a Claude Haiku per il refine (audio → testo ordinato), 3) il testo viene mostrato a te con conferma esplicita prima dell'invio al terminale.
Il testo non viene mai eseguito automaticamente: c'è sempre un click tuo di approvazione. Questa è una decisione di design safety-first: se Haiku interpreta male, tu vedi il diff prima.
Disclosure responsabile
Hai trovato una vulnerabilità? Scrivi a security@0identity.com. Rispondiamo entro 72h. Per bug ad alta gravità diamo bounty case-by-case (€100-1000 in base a impatto e qualità del report).
Non agire su sistemi di produzione · usa solo il tuo account o un account creato apposta per il test. Niente DoS, niente social engineering su personale, niente esfiltrazione di dati di altri utenti.
Cosa NON è coperto da garanzia
Sicurezza è un percorso continuo. Trasparenza richiesta:
- CSP
script-src 'unsafe-inline' 'unsafe-eval': richiesto dal runtime Next.js 15. Mitigazione futura: nonce-based CSP quando il framework lo supporta in modo stabile. - Bridge multi-worker: oggi il registro WebSocket è in-memory · su backend con più worker bisogna passare a Redis pubsub. Stato: SCAFFOLD, non bloccante perché il backend gira con un singolo worker.
- Encryption at rest del DB: gestita dal provider Hetzner a livello di disco (LUKS). Non implementiamo cifratura applicativa per i dati di sessione (i JWT sono firmati ma non cifrati).
- Backup off-site: dump giornalieri Postgres su storage Hetzner. Restore testato manualmente · automated DR drill in roadmap.
- Pen test esterno: il primo pen test indipendente è schedulato dopo il primo trimestre di lancio pubblico. Fino a quel momento, il check è interno.
Questa pagina è viva: la aggiorniamo ogni volta che cambiamo il modello di sicurezza. Per cambi rilevanti scriviamo agli iscritti via email.