# Security review pre go-live (prompt 34)

Data: 2026-10-05. Ambito: `apps/api`, `apps/public`, `apps/private`, `medusa/apps/backend`, `infra/` e `docker-compose.prod.yml`.
Metodo: lettura del codice e della configurazione, `npm audit`, test automatici, verifica nel browser (build di produzione del sito, area riservata servita da Caddy con la CSP di produzione).

Esiti: **ok** = conforme, nessuna modifica · **corretto** = trovato un problema e risolto in questa review · **da fare** = rimane aperto, con motivazione.

## Riepilogo

| # | Voce | Esito |
|---|---|---|
| 1 | Autenticazione, ruoli e ownership delle route `private/` e `admin/` | corretto |
| 2 | Input validati da schema, nessuna SQL concatenata | ok |
| 3 | Rate limit su auth, form pubblici, configuratore, upload | corretto |
| 4 | CORS, cookie, nessun token in localStorage | corretto |
| 5 | Upload: whitelist, dimensione, nomi rigenerati, path traversal | ok |
| 6 | HTML del blog sanitizzato, nessun `innerHTML`/`bypassSecurityTrust*` su contenuti non sanitizzati | ok |
| 7 | CSP senza `'unsafe-inline'` negli script (rimandata dal prompt 33) | corretto |
| 8 | Webhook Medusa e Stripe: firma e idempotenza | ok |
| 9 | Segreti fuori dal repo e dai log; `npm audit` senza alte/critiche | corretto / da fare |
| 10 | Errori in produzione senza stack; log senza password, token, carte | ok |
| 11 | Cookie banner: nessun cookie non tecnico prima del consenso | ok |
| 12 | Database: utente applicativo non superuser, utenti distinti per app e Medusa | ok |

## 1. Autenticazione, ruoli e ownership — corretto

- **Area admin**: tutte le route `/admin/*` stanno dietro un unico hook (`routes/admin/index.ts`). Prima controllava solo il ruolo nel JWT, quindi un admin disabilitato o declassato manteneva l'accesso fino alla scadenza del token (≤ 15 min).
  **Corretto**: un secondo hook rilegge l'utente dal DB (`requireActiveUser`) e richiede ancora `role = admin`. Disabilitato → 401, declassato → 403, subito. Test: `admin.test.ts` → "admin disabilitato o declassato".
- **Route private** (`/me*`, `/installer/profile`): `authenticate` / `requireRole("installer")` più `requireActiveUser` in ogni handler, che rilegge l'utente (disabilitato → 401). Verificato su tutti i file di `routes/private/`.
- **Ownership**: preventivi, ticket e messaggi filtrano sempre su `user_id` dell'utente corrente (`mine()`, `loadOwn()`). Risorsa altrui, in bozza o inesistente → 404 identico. Gli ordini Medusa sono filtrati sul customer dell'utente e ricontrollati sul dettaglio (`order.customer_id`). I carrelli sono verificati da `resolveCart`. I documenti seguono `visibleLevels`, riletti dal DB a ogni richiesta. Coperto dai test di `quotes`, `tickets`, `account`, `shop`, `documents`.
- **Ruolo admin non assegnabile** dalla registrazione (enum di `accountType`); JWT HS256 con algoritmo fissato in verifica.
- **Anti-enumerazione alla registrazione**: con un'email già registrata la risposta era 202 come le altre, ma più veloce (nessun hash argon2), quindi i tempi rivelavano l'email.
  **Corretto**: anche in quel caso si calcola l'hash (`auth.ts`). Il login usava già un hash fittizio.
- Medusa: le route `/internal/*` richiedono `x-internal-secret` (confronto `timingSafeEqual` su digest SHA-256); il dashboard ha whitelist IP e basic auth in Caddy.

## 2. Validazione e SQL — ok

- Ogni route Fastify dichiara gli schemi zod di body, query e params (`fastify-type-provider-zod`), più lo schema di risposta. Le route interne di Medusa validano con `validateAndTransformBody`.
- Nessun SQL concatenato: Drizzle parametrizza sempre. Nessun uso di `sql.raw`, `.unsafe()` o `execute` con stringhe composte. Le interpolazioni nei template `sql\`…\`` sono parametri (`tsQuery`, advisory lock). Le ricerche `ilike` fanno l'escape di `%`, `_` e `\` (`likeEscape`). Lo stesso vale in Medusa (claim con ILIKE letterale).

## 3. Rate limit — corretto

| Route | Limite per IP |
|---|---|
| globale | 300/min |
| login, reset password, verifica email, cambio password, cancellazione account | 5/min |
| registrazione, password dimenticata, reinvio verifica | 3 ogni 15 min |
| refresh | 30/min |
| `POST /contact`, `POST /showroom/bookings`, `POST /configurator/submit` | 5 ogni 15 min |
| `POST /configurator/evaluate`, `GET /forms/token` | 60/min |
| ticket: nuovo / messaggio | 10/ora, 30/ora |
| pagamento e completamento ordine | 20/min |

**Corretto**:
- **Upload admin** (`POST /admin/documents`, `/admin/uploads/image`, `/admin/quotes/:id/pdf`): avevano solo il limite globale. Ora 30/min (`UPLOAD_RATE_LIMIT`).
- **`POST /shop/cart/address`**: crea o cerca un customer guest in Medusa per ogni email e registra consensi. Ora 20/min.
- **IP reale dietro due proxy**: con `TRUST_PROXY=true` e il server SSR che chiama l'API su `http://api:3000`, tutte le richieste fatte durante il rendering arrivavano dall'IP del container del sito. Così condividevano un unico limite di 300/min: con un po' di traffico il sito avrebbe ricevuto 429 dall'API.
  - L'API ora accetta in `TRUST_PROXY` un elenco di proxy fidati. In produzione vale `loopback,uniquelocal`, cioè si fida di `X-Forwarded-For` solo dai container della rete Docker. Un client diretto non può falsificarlo, e Caddy sostituisce l'intestazione dei client.
  - Il server SSR inoltra l'`X-Forwarded-For` ricevuto da Caddy (`forwarded-for.interceptor.ts`), così ogni visitatore ha il suo limite.
  - Test: `app.test.ts` (IP da proxy fidato e da client diretto).
- Nota: il contatore del rate limit è in memoria, per processo. Va bene con una sola istanza dell'API; con più istanze serve lo store Redis di `@fastify/rate-limit`.

## 4. CORS, cookie, storage — corretto

- CORS: solo `CORS_ORIGINS` (sito e area riservata) con credenziali; il webhook ha `cors: false`.
- Cookie:

  | Cookie | Attributi |
  |---|---|
  | `iti_rt` | `HttpOnly`, `Secure`, `SameSite=Lax`, `Path=/auth` |
  | `cart_id` | firmato, `HttpOnly`, `Secure`, `SameSite=Lax` |
  | `iti_session` | non httpOnly (voluto: solo un indizio, valore `1`, nessun segreto) |
  | `iti_consent` | non httpOnly (voluto: lo legge il banner) |

- Token: access token solo in memoria in entrambe le app. In `localStorage` e `sessionStorage` ci sono solo configuratore, ultimo ordine e riepilogo dell'invio, senza token (verificato con grep e nel browser).
- **Corretto**: in produzione l'API ora **rifiuta di partire** con:
  - `AUTH_COOKIE_SECURE=false`;
  - origini CORS non `https://`;
  - `EMAIL_OUTBOX_DIR` impostata, che salverebbe su disco le email complete con i link di reset e di verifica, cioè token validi.

  Test in `app.test.ts`.

## 5. Upload — ok

- Whitelist per estensione **e** magic bytes **e** MIME dichiarato (SVG e HTML mai ammessi), `UPLOAD_MAX_BYTES` con conteggio in streaming (413) e cancellazione del file parziale.
- Chiavi generate dal server (`<uuid><ext>`), doppio controllo anti path traversal, scrittura con `wx`.
- `private/` mai servita staticamente: Caddy monta solo `uploads/public`. `media.<dominio>` ha `CSP sandbox` e `nosniff`.
- Coperto da `documents.test.ts` (14 casi) e dalla verifica del prompt 33.

## 6. HTML del blog e frontend — ok

- L'API converte il markdown con `marked` e poi lo filtra con `sanitize-html` (whitelist; niente `script`, `iframe`, `style`, `on*`, `javascript:`, `data:`).
- Nei frontend ci sono solo due `bypassSecurityTrustHtml`, entrambi su HTML che arriva da quel sanitizer: articolo del blog (`blog-post.ts`) e anteprima dell'editor (`blog-editor.ts`).
- Nessun altro `innerHTML`, `outerHTML` o `insertAdjacentHTML`.
- Verificato nel browser: markdown con `<img onerror>` e `<script>` nell'anteprima → tag rimossi, nessun codice eseguito.

## 7. Content-Security-Policy — corretto

Era il punto rimandato dal prompt 33: `'unsafe-inline'` negli script di entrambe le app.

**Sito (SSR) — nonce per risposta** (`apps/public/src/server/csp.ts`):
- `src/index.html` ha `ngCspNonce="__CSP_NONCE__"`. La build mette quel segnaposto come `nonce` sugli script e sugli stili inline e lo passa a beasties (CSS critici). Durante l'SSR, `CSP_NONCE` di Angular legge lo stesso attributo per lo script di avvio dell'event replay.
- Il server Express sostituisce il segnaposto con 128 bit casuali per ogni risposta HTML e invia l'intestazione CSP: `script-src 'self' 'nonce-…' https://js.stripe.com https://*.js.stripe.com`, `connect-src` sull'API e Stripe, `img-src` su `PUBLIC_MEDIA_URL` (nuova variabile) e tile OSM, `frame-ancestors 'none'`.
- Con `ng serve` la CSP non viene inviata.
- Caddy non sovrascrive più la CSP del sito. Imposta solo un default restrittivo (`?Content-Security-Policy`) per le risposte che non ce l'hanno: statici ed errori. Verificato con Caddy reale: la CSP con nonce passa invariata, gli statici ricevono il default.

**Area riservata** (statica): `inlineCritical: false` nella build di produzione, quindi l'`index.html` non contiene più script inline. CSP `script-src 'self'`.

**Verificato nel browser**:
- sito (build di produzione + API e Medusa reali): idratazione, stylesheet attivato dallo script di beasties con il nonce, aggiunta al carrello funzionante; uno script inline iniettato viene **bloccato** (`script-src-elem`);
- area riservata servita da Caddy con la CSP di produzione: login, dashboard admin ed editor del blog senza violazioni.

`style-src 'unsafe-inline'` resta: servono gli stili dei componenti Angular e gli attributi `style` di Leaflet. Il rischio è basso, perché gli script restano bloccati.

## 8. Webhook — ok

- **Medusa → Fastify**: HMAC-SHA256 sul body grezzo verificato prima del parse, con `timingSafeEqual`. Idempotenza su `webhook_events` (id UUID v5 deterministico, lock `FOR UPDATE`). Coperto da `webhooks.test.ts` (13 casi).
- **Stripe → Medusa**: la firma la verifica il provider ufficiale `payment-stripe` (`webhookSecret`). Caddy espone solo `/hooks/payment/stripe_stripe`. L'elaborazione di Medusa è idempotente sullo stato della payment session (un evento ripetuto non cattura due volte).
- **Corretto**: in produzione Medusa ora avvisa all'avvio se c'è `STRIPE_API_KEY` ma manca `STRIPE_WEBHOOK_SECRET`.
- **Da fare**: il flusso Stripe reale (pagamento, 3DS, webhook firmato) non è ancora verificato end-to-end. Servono le chiavi di test (vedi prompt 13 e 26).

## 9. Segreti e dipendenze — corretto / da fare

- **Repo**: i file `.env*` (tranne gli `.example`), `*.private.env.json`, `uploads/`, `backups/` e `.outbox/` sono in `.gitignore`. Una ricerca di chiavi Stripe, Brevo, Resend e PEM tra i file che finirebbero nel repo non trova nulla; gli `.example` hanno solo segnaposto.
  **Corretto**: aggiunto `*.stackdump` (dump dei crash di Git Bash, due file non tracciati nel working tree).
- **Log**: redatti `authorization`, `cookie`, `set-cookie`, `x-internal-secret`, `x-signature`. I body non vengono mai loggati. I token viaggiano solo nel body o nei cookie, mai negli URL dell'API. Il trasporto email `console` logga solo destinatario, template e oggetto.
- **Corretto**: in produzione `medusa-config.ts` ora rifiuta di partire se `JWT_SECRET`, `COOKIE_SECRET`, `INTERNAL_API_SECRET` o `WEBHOOK_SECRET` mancano o hanno meno di 32 caratteri. Senza `JWT_SECRET`, Medusa userebbe il default `supersecret`.
- **`npm audit` del monorepo**: 0 vulnerabilità nelle dipendenze di produzione. Ci sono 4 *moderate* solo di sviluppo (`esbuild` dentro `drizzle-kit`, server di sviluppo mai avviato; il fix proposto è un downgrade).
- **`npm audit` di Medusa**: prima 110 *high*, tutte transitive dal pacchetto `@medusajs/*`, da due sole cause.
  - **lodash ≤ 4.17.23** (prototype pollution in `_.unset`/`_.omit`, code injection in `_.template`). **Corretto**: `overrides.lodash = ^4.18.1` in `medusa/package.json` e lockfile aggiornato. Una sola copia, 4.18.1; Medusa si avvia e interroga il DB (`medusa exec` verificato).
  - **braces ≤ 3.0.3** (stack exhaustion con pattern glob annidati). **Da fare**: non esiste una versione corretta (3.0.3 è l'ultima). Il pacchetto arriva da `fast-glob`/`micromatch` (caricamento dei moduli all'avvio) e dal bundler del dashboard (build). Non riceve mai pattern da input esterni, quindi non è sfruttabile. Le 77 *high* di produzione che restano sono tutte questa catena. Da ricontrollare a ogni aggiornamento di Medusa.

## 10. Errori e log in produzione — ok

- Mai stack trace nelle risposte. I 5xx rispondono `"Errore interno"` in produzione (test `app.test.ts`); gli errori di Medusa diventano 503/502 generici, con il dettaglio solo nei log.
- Password: solo hash argon2id. Token: solo SHA-256 in DB (test `auth.test.ts`: nessun segreto nel dump del DB né nei log catturati).
- Dati carta: non passano mai dai server, perché il Payment Element di Stripe li invia direttamente a Stripe.

## 11. Cookie banner — ok

Verificato nel prompt 28 e invariato:
- alla prima visita nessun cookie e nessuna risorsa di terzi;
- `iti_consent` viene scritto solo dopo la scelta;
- i cookie di sessione e carrello sono tecnici, e nascono solo con login o aggiunta al carrello;
- Stripe si carica solo al passo di pagamento (necessario al servizio richiesto);
- le tile OSM si caricano solo dopo il clic su "Mostra mappa".

Oggi il sito non ha script di statistica o marketing; `ConsentService` è il punto da usare per quelli futuri.

## 12. Database — ok

- `iti_app` e `iti_medusa` sono utenti distinti. Nessuno dei due è superuser e non hanno `CREATEROLE`, `CREATEDB` né `BYPASSRLS` (verificato su `pg_roles`).
- Ciascuno è proprietario solo del proprio database; `CONNECT` è revocato a `PUBLIC`.
- Le estensioni le crea l'init del container (superuser), non le migrazioni.
- Postgres e Redis stanno sulla rete Docker `internal`, senza porte pubblicate.
- **Da fare** (minore): l'init crea anche `iti_app_test` in produzione, dove non serve. Dopo il primo deploy si può eliminare con `DROP DATABASE iti_app_test`.

## Punti rimasti aperti

1. **Stripe end-to-end** (pagamento, 3DS, carta rifiutata, webhook firmato): non verificato, mancano le chiavi di test (prompt 13 e 26).
2. **braces** nelle dipendenze di Medusa: nessuna correzione upstream, non sfruttabile; ricontrollare agli aggiornamenti di Medusa.
3. **Rate limit in memoria**: con più istanze dell'API, passare allo store Redis.
4. **HTTPS reale e HSTS**: certificati Let's Encrypt e DNS da verificare sulla VPS. HSTS è senza `includeSubDomains`/`preload`, una scelta voluta (prompt 33).
5. **Immagini esterne negli articoli del blog**: la CSP le blocca (`img-src` limitato a self, media, OSM e Stripe). Le immagini vanno caricate dall'editor.
6. **GDPR**: la cancellazione effettiva dei dati dopo la richiesta dell'utente è manuale; privacy e cookie policy sono da validare con il consulente.
7. **`iti_app_test` in produzione**: da eliminare dopo il primo deploy.
8. **Utenti del dashboard Medusa**: password robuste e whitelist IP (`SHOP_ADMIN_ALLOWED_IPS`) sull'ufficio o sulla VPN; il default ammette tutti, protetti solo dalla basic auth.