Validatore Configurazione Nginx

Un nginx.conf difettoso di solito si manifesta in uno di due modi spiacevoli: `nginx -t` che rifiuta il reload con un criptico errore di numero di riga oppure, peggio, un `reload` che mantiene in memoria la vecchia configurazione funzionante mentre quella nuova, rotta, resta su disco, così sembra tutto a posto fino al successivo riavvio completo. Entrambe le situazioni si evitano intercettando prima lo stesso tipo di errori, mentre stai ancora modificando.

L'errore più comune nei veri nginx.conf non ha nulla di esotico: è un punto e virgola dimenticato. Poiché la grammatica di nginx dà peso solo a `;`, `{` e `}` (non agli a capo), un `;` mancante non produce un chiaro "riga 12: atteso ;" come in gran parte dei parser moderni; invece nome e argomenti della direttiva successiva vengono assorbiti in silenzio come argomenti extra della precedente, a volte senza alcun errore finché qualcosa a valle non si comporta in modo strano. L'euristica sugli a capo di questo strumento controlla proprio questo schema, cioè il nome di una direttiva nota che compare a metà dell'elenco di argomenti in una nuova riga del sorgente, e lo segnala prima che diventi un ticket di assistenza.

La posizione delle direttive è la seconda trappola frequente: `proxy_pass` ha senso solo dentro un blocco `location` (o `if`), `listen`/`server_name` solo dentro `server`, e così via, ma il parser di nginx non rifiuta una direttiva solo perché è in un posto insolito se il nome è comunque riconosciuto in senso più ampio, e i messaggi di errore fanno riferimento al registro interno delle direttive di nginx anziché dire "hai annidato male questa". Questo validatore controlla direttamente la tabella direttiva-contesto, così un `proxy_pass` lasciato per errore a livello `http` (fuori da qualsiasi `server`/`location`) viene segnalato con la riga esatta, non con un generico "la configurazione non si è caricata".

Oltre alla sintassi, alcune piccole scelte di configurazione hanno conseguenze di sicurezza sproporzionate: lasciare `server_tokens` al valore predefinito (`on`) mostra la tua versione esatta di nginx in ogni header di risposta e nella pagina di errore predefinita, una ricognizione gratuita per chi cerca una CVE specifica di quella versione; usare la variabile `$uri`, decodificata dall'URL, dentro un `return`/`rewrite`/`add_header` (invece del grezzo `$request_uri`) può in certe configurazioni permettere a un attaccante di iniettare caratteri in una destinazione di reindirizzamento. Nessuna delle due cose rompe qualcosa in modo visibile durante i test normali, ed è proprio per questo che meritano un controllo dedicato invece di affidarsi a individuarle a occhio in una configurazione di 200 righe.