Note di sicurezza

Cosa posso dimostrare

La sicurezza è la cosa più facile da dichiarare e la più difficile da dimostrare. Qui c’è quello che ho testato davvero, quello che ho rafforzato e quello che sto ancora imparando — con i comandi per verificarlo.

Testato
Rafforzato
In apprendimento

Testato

Verifiche riproducibili su sistemi che posso toccare.

Questo sito è un export statico: nessun codice server, nessun database, nessun form, nessun cookie. Non c’è superficie di sessione o di injection.
Dipendenze: bun audit riporta 0 vulnerabilità note su 103 pacchetti.
Nessuno script o CDN di terze parti. Font self-hosted, nessuna analytics, nessuna API esterna per i font.
Ogni link esterno si apre con rel="noreferrer".
Nessun segreto nel repository: i file .env* sono ignorati e non ci sono chiavi.
Parser della configurazione di PipeDuck: le righe malformate vengono rifiutate con il numero di riga e le soglie numeriche vengono limitate, non prese per buone.

Rafforzato

Le impostazioni intorno al codice, non solo il codice.

main è protetto: ogni modifica richiede review e i check obbligatori, anche per il proprietario.
Due check obbligatori: build e una verifica che ogni modifica chiuda una issue reale.
Il token del workflow dichiara contents: read; il deploy Pages aggiunge pages: write e id-token: write.
Nessun collaboratore e nessun invito pendente. Force-push e cancellazione del branch sono bloccati.
Solo storia lineare: squash o rebase, niente merge commit.

In apprendimento

Detto chiaramente, perché fingere il contrario sarebbe una bugia.

CTF: pratica continua. Un training lab pubblico qui sotto; altri write-up in arrivo.
Bug bounty: appena iniziato. Nessun report accettato.
Nessuna certificazione di sicurezza. Non vendo penetration test.
Training lab: BOLA/IDOR in un'API locale di fatture — riproduzione, impatto, fix e test di regressione.

Prova pubblica / training lab

BOLA/IDOR in un'API di fatture

L'autenticazione funziona; l'autorizzazione a livello di oggetto no. Un'API locale e sintetica riproduce la fattura di un altro tenant, poi la corregge e dimostra entrambi gli stati con un test di regressione. Deliberatamente vulnerabile, solo loopback, non un incarico per un cliente.

Esercizio di formazione, non un CVE reale.

Leggi il lab

Modello di minaccia

Cosa può andare storto nelle due cose che mantengo, e lo stato attuale di ogni mitigazione.

Questo sitoDefacement attraverso il repositoryVerificatomain protetto, check obbligatori, token contents: read, nessun collaboratore.

Questo sitoCodice di terze parti iniettato in buildVerificatoDipendenze bloccate dal lockfile, zero vulnerabilità note, nessuno script esterno.

Questo sitoHeader di sicurezza del browser assentiApertoGitHub Pages non permette header personalizzati: niente CSP, niente X-Frame-Options. Su un host custom li imposterei.

PipeDuckValori malformati o ostili nel file di configurazioneVerificatoIl parser rifiuta le righe errate con il numero di riga e limita percentuali e soglie; coperto dai test di configurazione.

PipeDuckAudio perso quando il ducking si ferma o il sink fallisceVerificatoIl sink virtuale ha un percorso di abbandono come fallback e i fallimenti di ripristino sono testati.

PipeDuckSuperficie tray e D-BusApertoNon ancora modellata. È il prossimo punto.

Verificalo tu

Gli stessi tre comandi che ho eseguito, con l’output ottenuto.

$ bun audit
No vulnerabilities found (checked 103 packages)
$ curl -sI https://errusso.github.io
strict-transport-security presente · content-security-policy assente (GitHub Pages)
$ git ls-files | grep -i env
(nessun output — nessun file di ambiente tracciato)

Cosa non è questa pagina

Non è un portfolio da penetration tester. Non sono stato pagato per entrare nel sistema di qualcuno e non lo dirò mai. Il lab è un esercizio locale deliberatamente vulnerabile, non un finding su un cliente. Tutto ciò che c’è sopra o è verificabile in questo repository o è dichiarato esplicitamente come in apprendimento.