Dichiarazione Tecnica di Privacy e Sicurezza

Aggiornata il 07/04/2026 - Documento tecnico operativo su autenticazione, sessione, protezione API e accesso ai dati.

1) Stato Compliance (Tecnico)

Autenticazione, autorizzazione API, rate-limit e hardening header sono applicati lato backend.
Le preferenze notifiche sono gestite anche lato server: l'invio push rispetta opt-in/opt-out per categoria.
I consensi privacy/termini sono versionati e registrati con timestamp lato backend.
Sono disponibili endpoint self-service per export dati e cancellazione account.

2) Dati Trattati e Finalita

Dati account: email, credenziali, token di sessione per login e sicurezza accesso.
Dati profilo: nome, nickname, scuola/citta e campi profilo per funzionalita social/app.
Dati contenuto: post, spotted, commenti e interazioni necessari al servizio.
Dati notifiche: token push e preferenze notifiche per recapito comunicazioni richieste.
Dati di sicurezza: rate-limit tecnici, log errori e metadati minimi per prevenzione abusi.

3) Basi Giuridiche Operative

Esecuzione del servizio richiesto dall'utente: autenticazione, profilo, funzionalita core.
Legittimo interesse alla sicurezza: anti-abuso, protezione API, monitoraggio anomalie tecniche.
Consenso esplicito dove richiesto: notifiche opzionali e presa visione/accettazione legale onboarding.

4) Consenso Notifiche (Server-Side)

Preferenze gestite per categoria: push, post, assembly, spotted, reengagement, event.
Il consenso generale push disattiva tutte le notifiche lato backend.
I sender push applicano filtro preferenze prima dell'invio verso Expo Push API.
Le preferenze sono aggiornabili via GET/PUT /api/notification-preferences.

5) Consensi Legali Versionati

Registrazione consensi onboarding via POST /api/save-legal-consent.
Persistenza di versione informativa/termini, timestamp, canale sorgente e metadati tecnici minimi.
Obiettivo: tracciabilita auditabile delle accettazioni per versione documento.

6) Diritti GDPR (Self-Service)

Export dati personali autenticato: GET /api/export-my-data.
Cancellazione account autenticata: DELETE /api/delete-my-account.
Le operazioni sono protette da autenticazione e rate-limit.

7) Misure di Sicurezza Applicate

Headers di sicurezza: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
Protezione endpoint mutanti: limiti payload + rate-limit IP/email (best effort su serverless).
Controlli anti-enumerazione sui flussi auth pubblici.
Allowlist redirect OAuth/app e protezione endpoint interni con shared secret fail-closed.
Validazione upload con MIME + magic-bytes + limiti dimensione.
RLS e accesso owner-scoped per tabelle sensibili lato database.

Trasmissione del token

Tutti i token di autenticazione vengono trasmessi esclusivamente nell'header HTTP Authorization: Bearer <token>, mai nel body della richiesta né come parametro URL.
Unica eccezione: il refresh_token viene inviato nel body JSON all'endpoint POST /api/auth-refresh, sempre su canale HTTPS.
Il backend estrae e valida il token solo dall'header Authorization tramite la funzione extractToken().

Storage dei token per piattaforma

App mobile (Expo/React Native): i token sono conservati in SecureStore, che utilizza il Keychain (iOS) e il Keystore (Android) — storage cifrato a livello di sistema operativo, non accessibile da altri processi o script. Un fallback in memoria è utilizzato solo quando SecureStore non è disponibile (es. ambienti web); i token in memoria non persistono al reload.
Pannello web: i token sono salvati in sessionStorage (non persistono oltre la sessione del tab/browser). Eventuali token legacy in localStorage vengono migrati automaticamente a sessionStorage e rimossi dallo storage persistente.

Rischi noti e mitigazioni (storage web)

sessionStorage e localStorage sono accessibili da qualsiasi script JavaScript eseguito nella pagina. In caso di attacco XSS (Cross-Site Scripting), un codice malevolo iniettato potrebbe leggere il token.
Scelta tecnica coerente con architettura SPA statica + API serverless con Bearer token, senza layer server-side per session cookie HttpOnly.
Mitigazioni attive: Content Security Policy (CSP) restrittiva, sanitizzazione input, header di sicurezza (X-Content-Type-Options, X-Frame-Options), hardening continuo frontend.
I JWT Supabase hanno scadenza breve (~1 ora), limitando la finestra di utilizzo di un token eventualmente compromesso.
Mitigazione futura raccomandata: migrazione a cookie HttpOnly + Secure + SameSite=Strict per il pannello web, con protezione CSRF lato server.

9) Conservazione Dati (Linee Tecniche)

Lato browser: token rimossi al logout; token legacy migrati da localStorage a sessionStorage.
Lato API: bucket di rate-limit in memoria con finestre tecniche tra 15 e 60 minuti (non storage persistente).
Lato database: dati account/profilo mantenuti fino a richiesta di cancellazione o cancellazione amministrativa secondo processi operativi.
Lato log infrastrutturali (runtime/provider): retention gestita da configurazioni della piattaforma (Netlify/Supabase), non hardcodata nel codice applicativo.

Storage immagini e accesso pubblico

Le immagini caricate (post e avatar) sono conservate nel bucket Supabase Storage images, organizzato in cartelle posts/{userId}/{timestamp}.ext e avatars/{userId}/{timestamp}.ext.
Il caricamento avviene solo tramite l'endpoint autenticato POST /api/upload-image (Bearer token obbligatorio, rate-limit per IP e per utente, validazione MIME e magic bytes, limite 8 MB).
Rischio noto — URL pubblici: gli URL restituiti sono generati con getPublicUrl() e sono accessibili senza autenticazione. Chiunque possieda o indovini l'URL può visualizzare l'immagine. L'URL del progetto Supabase è visibile nel codice sorgente del client e nelle richieste di rete del browser.
Rischio di enumerazione: la struttura dei path ({userId}/{timestamp}) è parzialmente predicibile; un attaccante potrebbe tentare di enumerare immagini provando combinazioni di user ID e timestamp.
Mitigazioni attive: il caricamento è protetto da autenticazione e rate-limit; la cancellazione delle immagini avviene solo tramite endpoint protetti (DELETE /api/delete-post con verifica ownership).
Mitigazioni future raccomandate:
1. Passare da URL pubblici a signed URL con scadenza (createSignedUrl()), così ogni link è valido solo per un tempo limitato e richiede autenticazione server-side per essere generato.
2. In alternativa, rendere il bucket privato e servire le immagini tramite un endpoint proxy autenticato.
3. Aggiungere un segmento random (UUID) al path di upload per rendere gli URL non predicibili.
4. Abilitare RLS esplicito sullo storage Supabase (storage.objects) per limitare le operazioni per ruolo e owner.

10) Sub-processor Tecnici

Supabase: autenticazione e database applicativo.
Netlify: hosting statico e runtime serverless API.
Expo Push Service: recapito notifiche push ai device.

11) Incident Response

Gestione incidenti con contenimento, analisi impatto, correzione e hardening successivo.
Escalation interna su eventi sicurezza con prioritizzazione per severita.

12) Trasparenza e Limiti Documento

Questa pagina descrive controlli tecnici e operativi implementati nel codice.
Per il testo legale definitivo (titolare, art. 13/14 GDPR, tempi specifici, DPO se presente) serve l'informativa legale ufficiale pubblicata dal titolare.
Ogni modifica a policy, endpoint, basi giuridiche operative o retention deve aggiornare questa pagina.

Torna alla pagina di login