La sicurezza delle applicazioni che costruiamo e gestiamo — controlli scritti nel codice, verificabili dall’esterno, senza certificazioni che non abbiamo.
Il lavoro copre la sicurezza dell’applicazione e l’ingegneria della riservatezza: intestazioni e politica dei contenuti, limitazione del tasso, posizione predefinita «chiuso» delle verifiche, crittografia dei segreti, log che non possono essere riscritti, anonimizzazione dei dati e termini di conservazione inseriti nel codice, non solo nella politica. Non siamo revisori certificati e non emettiamo certificati.
Già costruitoHo scelto «consegnato» per un ambito volutamente ristretto, e il limite lo scriviamo prima dell’elenco delle capacità. I controlli descritti qui sotto girano su sistemi propri e una parte si possono verificare dall’esterno già ora: il rate limiting si dimostra con dodici richieste consecutive (la decima riceve 429, verificato in produzione il 06.09.2026), la health probe restituisce solo valori booleani, e gli header di sicurezza si leggono dalla risposta. La seconda e la terza implementazione citate sono la piattaforma di segnalazioni — politica di contenuto con valore unico per risposta, lista bianca di destinazioni di rete verificata in integrazione continua, autenticazione a due fattori obbligatoria per il personale — e il client di firma elettronica scritto senza alcuna nuova dipendenza, con difesa contro il wrapping della firma XML. Ciò che la prova NON supporta: non abbiamo alcuna certificazione, non facciamo test offensivi come servizio, non gestiamo un centro di monitoraggio e non emettiamo attestati di conformità.
La maggior parte dei buchi che abbiamo trovato nei nostri sistemi non erano exploit sofisticati. Erano valori predefiniti. Un percorso che avviava una chiamata telefonica verso qualsiasi numero, senza autenticazione, che nessun componente dell’interfaccia chiamava più da tempo. Un controllo di origine che passava quando la lista era vuota. Un indirizzo IP completo inviato in un messaggio di notifica, mentre la pagina pubblica prometteva anonimizzazione. Tutti e tre erano scritti nel nostro codice e nessuno di essi sarebbe emerso in uno scanner automatico.
Da qui deriva la forma del servizio. Non vendiamo un rapporto di scansione. Leggiamo il codice con una domanda precisa: quando questa verifica non può decidere, che cosa fa — consente o rifiuta? La posizione predefinita è la differenza tra un gate e una decorazione. Nei nostri sistemi, il gate di consumo restituisce «non consentito» in caso di eccezione, e la rotta di chiamata telefonica risponde 404 se il segreto non è configurato — cioè la funzione è spenta se qualcuno non l’ha avviata deliberatamente.
La seconda metà del lavoro è l’ingegneria della riservatezza, perché nella pratica le due cose non si separano. Il termine di conservazione dichiarato pubblicamente non significa nulla se non è applicato dal codice. Da noi, il registro delle richieste elimina i file più vecchi del termine dichiarato, con il numero di giorni preso dallo stesso valore che compare nella politica pubblicata. In un altro sistema, la tabella di retention tiene accanto a ogni termine il testo pubblicato, parola per parola, e la base giuridica — così che la politica e il database non possano divergere l’una dall’altro in silenzio.
Ciò che pubblichiamo su noi stessi fa parte del metodo. La politica di contenuto di questo sito consente `unsafe-inline` e `unsafe-eval` negli script. È una debolezza reale e la scriviamo qui, non in un rapporto interno — è stato persino il meccanismo con cui il nostro stesso audit di accessibilità ha potuto iniettare uno strumento di verifica direttamente nella pagina di produzione. Un fornitore che non pubblica le proprie debolezze note non può trovarle nelle vostre.
Cosa comprende
Il lavoro, per componenti
Leggiamo la posizione predefinita di ogni controllo
La domanda centrale dell’analisi: quando il controllo non può decidere, consente o rifiuta? Esempio reale, dal nostro stesso codice, marcato come tale: la lista delle origini consentite di un widget lascia passare il controllo se la lista è vuota — scelta deliberata di compatibilità con le installazioni vecchie, scritta nel commento, ma che significa che la restrizione per dominio deve essere configurata esplicitamente a ogni implementazione. Controesempio: la gate di consumo che a qualsiasi eccezione restituisce «non consentito».
Limitazione di frequenza corretta dietro un proxy
Dieci richieste al minuto per indirizzo, con una sottigliezza che decide se il limite funziona o no: la chiave viene presa dall’ultimo salto dell’intestazione di inoltro, non dal primo. Il nostro proxy aggiunge l’indirizzo reale alla fine di ciò che ha inviato il client, quindi la prima voce è controllata dall’attaccante — chi la usa può superare il proprio limite inviando valori casuali. È verificabile dall’esterno: dodici richieste consecutive producono nove risposte riuscite, poi 429.
Intestazioni e politica di contenuto, con valore unico per risposta dove possibile
Su questo sito: trasporto rigoroso per due anni con sottodomini e inserimento nella lista di precaricamento, tipo di contenuto non deducibile, politica di riferimento ristretta, politica dei permessi che chiude la camera e lascia microfono e localizzazione solo per la propria pagina. Sulla piattaforma delle segnalazioni, più restrittivo: la politica di contenuto riceve un valore unico a ogni risposta, generato nel proxy, senza fonti terze per script, connessioni o font, e l’incapsulamento in frame è completamente rifiutato.
Lista bianca di destinazioni di rete, verificata automaticamente
In un progetto pubblico, gli indirizzi che l’applicazione ha il permesso di contattare sono una lista verificata da un comando eseguito nell’integrazione continua, sia in modo statico sia in esecuzione. Un nuovo pacchetto che comincia a telefonare a casa viene bloccato dal controllo, non in produzione. È il controllo che intercetta esattamente la classe di incidenti della catena di approvvigionamento da cui nessuno si protegge con uno scanner di vulnerabilità.
I segreti non finiscono in risposte, log o notifiche
Il probe di salute del modulo di contatto restituisce solo valori booleani — se è configurato, se l’accredito è valido, se il log può essere scritto — mai il token, l’identificatore della conversazione o il nome del bot. I token di canale della piattaforma di messaggistica sono conservati cifrati. I log degli avvisi passano attraverso un modulo di redazione dei dati personali prima della scrittura.
Anonimizzazione applicata prima della scrittura, non dopo
L’indirizzo IP viene troncato al prefisso di rete — /24 per IPv4, /48 per IPv6 — prima di entrare nel registro o in una notifica. Con due dettagli importanti: si prende l’ultimo salto, non il primo, per lo stesso motivo del rate limiting; e gli indirizzi IPv4 segnalati in forma mappata IPv6 vengono riconosciuti e trattati come IPv4, altrimenti verrebbero conservati integri, cioè esattamente al contrario dello scopo.
Registro che aggiunge, non riscrive
Le richieste tramite modulo vengono scritte in un registro con aggiunta, un oggetto per riga, con permessi 0600 sul file e 0700 sulla directory, prima di tentare la consegna. Il motivo è un guasto reale: quando il canale di notifica è andato giù, l’endpoint restituiva 500 e ogni richiesta si perdeva senza traccia. Ora un canale guasto significa «dobbiamo guardare nel file», non «la richiesta non è mai esistita». Il risultato della consegna viene scritto come seconda riga, con lo stesso identificatore.
Il termine di conservazione applicato dal codice, non solo dichiarato
Il registro delle richieste elimina i file più vecchi del termine dichiarato pubblicamente, con il numero di giorni preso dallo stesso valore. In un altro sistema, la tabella di retention tiene accanto a ogni termine il testo pubblicato parola per parola e il fondamento giuridico, e la funzione di pulizia segnala per impostazione predefinita ciò che eliminerebbe; l’eliminazione reale richiede un argomento esplicito. L’eliminazione silenziosa è una modalità di errore, non una funzione.
Identità e firma, quando il progetto le richiede
Abbiamo scritto, da zero e senza nuove dipendenze, un fornitore di servizi per l’autenticazione federata e un client per la firma elettronica. L’analizzatore XML non elabora definizioni di tipo di documento, quindi la classe di attacchi tramite entità esterne non si applica; la verifica della firma restituisce il nodo coperto dalla firma, non un valore logico, e il chiamante è obbligato a confrontare l’identità dell’oggetto — difesa contro l’inquadramento della firma. La canonicalizzazione è stata verificata sui vettori ufficiali della specifica.
Come si presenta
Il percorso, passo dopo passo.
01
Stabiliamo l’ambito e ciò che non abbiamo il diritto di toccare
Per iscritto, prima di qualsiasi comando: quali sistemi, quale periodo, quali tipi di verifica sono consentiti e chi è la persona di contatto se qualcosa si interrompe. Consegnamo: il documento di ambito firmato e l’elenco dei sistemi esclusi.
02
Leggiamo il codice e la configurazione, con enfasi sulla posizione predefinita
Le verifiche che non possono decidere, i segreti che finiscono nelle risposte o nei registri, i percorsi che nessuno chiama più ma restano aperti, le intestazioni mancanti. Consegnamo: le constatazioni con file e riga, ordinate in base a ciò che si può fare con esse, non in base alla severità teorica.
03
Ripariamo o descriviamo esattamente la riparazione
Dove abbiamo accesso, introduciamo il controllo e scriviamo il test che lo mantiene al suo posto — una verifica che non ha un test si perde alla prima rifattorizzazione. Dove non abbiamo accesso, consegnamo la modifica descritta in modo sufficientemente preciso perché il team del cliente possa applicarla senza chiedercelo di nuovo.
04
Colleghiamo la riservatezza al codice
Il termine di conservazione, l’anonimizzazione e l’elenco dei destinatari diventano valori nel codice, con il testo pubblicato accanto. Consegnamo: il registro dei trattamenti compilato, con la colonna «dove è implementato» piena, e l’elenco dei punti ancora da decidere, con chi decide ciascuno.
05
Verifichiamo dall’esterno ciò che si può verificare dall’esterno
Le intestazioni, il comportamento al limite, ciò che restituiscono le sonde di salute. Consegnamo: i comandi esatti di verifica, così che chiunque — incluso un auditor del cliente — possa ripetere la verifica senza di noi.
Gli strati che tocchiamo, dall'alto verso il basso
I dati
Cosa tocchiamo, dove risiedono e quanto rimangono
Le domande che pone chiunque abbia un responsabile della protezione dei dati — poste qui prima che le ponga lui.
Cosa tocchiamo in un’analisi
Il codice, la configurazione del server, gli header delle risposte e, dove opportuno, lo schema del database e le politiche di accesso riga per riga. Non abbiamo bisogno dei dati reali dei clienti per eseguire l’analisi e preferiamo non toccarli affatto.
Che cosa non facciamo senza ambito autorizzato per iscritto
Nessuna azione che produca traffico contro un sistema in esercizio. Le verifiche in produzione che compaiono in questa pagina sono normali richieste di lettura, su sistemi propri. Qualsiasi superamento di questo limite richiede un’autorizzazione scritta, con periodo e indirizzi, firmata da chi ha il diritto di concederla.
Dove finiscono le constatazioni
In un documento con una constatazione per riga: dove si trova, cosa si può fare con essa, che cosa la corregge e come si verifica la correzione. Le constatazioni che descrivono un percorso di sfruttamento non circolano attraverso canali non sicuri e non finiscono in materiali pubblici prima della riparazione.
Registro dei trattamenti
Per la parte di riservatezza, il risultato è un registro con una riga per attività: finalità, base giuridica, categorie di dati, destinatari, trasferimenti, luogo di archiviazione, termine, misure e il file nel codice in cui è implementato. Ciò che non è stato possibile verificare si scrive «non verificato», non si completa da un modello.
La regola che tiene la politica incollata al codice
Se una modifica del codice cambia ciò che viene raccolto, a chi arriva o per quanto tempo viene conservato, la politica pubblicata si modifica nello stesso passo di rilascio. La divergenza tra la politica pubblicata e il codice è stata esattamente il problema che ci ha portato a scrivere il nostro registro.
Un caso
Un percorso dimenticato che poteva telefonare a chiunque
La situazione
In una revisione del nostro sito abbiamo trovato un percorso di interfaccia di programmazione che avviava una chiamata telefonica verso qualsiasi numero inviato nel corpo della richiesta. Senza autenticazione, a spese e dal numero dell’azienda. Nessun componente dell’interfaccia lo chiamava più — l’unico chiamante era un elemento che non veniva più mostrato. In altre parole, era funzionato apertamente verso internet senza che nessuno avesse motivo di guardarlo.
Cosa abbiamo costruito
Lo abbiamo trattato come due problemi, non uno. Tecnico: il percorso ora richiede un segreto condiviso in un header, e se il segreto non è configurato affatto risponde 404 — la capacità è disattivata se qualcuno non la attiva deliberatamente, non attiva finché qualcuno non la ferma. Giuridico ed etico: una chiamata automatica non richiesta è un trattamento di dati che la persona chiamata non ha richiesto, quindi abbiamo scritto nel registro ciò che sarebbe necessario per un’eventuale riattivazione — base giuridica documentata rispetto al chiamato, evidenza del consenso e un canale di opposizione.
Cosa è emerso
La capacità è chiusa per impostazione predefinita e resta chiusa finché qualcuno non prende una decisione esplicita. La riga nel registro dei trattamenti descrive lo stato, com’era prima, il rischio e le condizioni di riattivazione — così la prossima persona che trova il percorso non deve ricostruire il ragionamento.
Cosa non dice il caso
Non ce ne siamo accorti tramite uno strumento. L’abbiamo trovata leggendo i percorsi uno per uno e chiedendo, per ciascuno, chi lo chiama. Uno scanner automatico avrebbe visto un percorso che restituisce 400 a una richiesta vuota e sarebbe andato oltre. È anche il limite del metodo: copre ciò che leggiamo, e ciò che non leggiamo resta non coperto — per questo il dominio si stabilisce per iscritto.
Domande
Cosa ci chiedono le persone prima di chiamare
Avete certificazioni di sicurezza?
No. Né ISO 27001, né SOC 2, né una certificazione di test offensivi, né l’accreditamento di auditor. Non emettiamo certificati e non firmiamo attestazioni di conformità. Ciò che possiamo mostrare è la nostra pratica interna, con file e riga, e i controlli che abbiamo inserito nei sistemi in esercizio. Se ti serve un certificato per un dossier, ti serve un organismo accreditato, non noi — ed è meglio saperlo subito.
Eseguite test di penetrazione?
Non come servizio. Non abbiamo un team di test offensivi, licenza o metodologia certificata, e non fingiamo di averli. Quello che facciamo è analisi del codice e della configurazione, più verifiche non invasive dall’esterno — header, comportamento al limite di velocità, cosa rivelano le risposte di errore. Se il progetto richiede un vero test offensivo, ti serve una società specializzata; possiamo lavorare al suo fianco sulla parte di correzione.
Che cosa avete trovato nei vostri sistemi?
Tre cose, in una sola giornata di analisi, tutte scritte pubblicamente nel nostro registro. Un percorso che avviava una chiamata telefonica verso qualsiasi numero nel corpo della richiesta, anonimo, senza autenticazione, che nessun componente dell’interfaccia richiamava più — ora risponde 404 se il segreto non è configurato, cioè è disattivato se qualcuno non lo avvia deliberatamente. Un widget di conversazione che si caricava a ogni visualizzazione e scriveva la sessione nella memoria del browser prima che il visitatore chiedesse qualcosa — ora si carica alla pressione del pulsante. E l’indirizzo IP completo inviato in una notifica, mentre la pagina pubblica prometteva anonimizzazione — ora viene troncato prima della scrittura.
La vostra politica dei contenuti consente `unsafe-eval`. Perché dovrei credervi?
Perché ve l’abbiamo detto noi, non lo avete scoperto voi. Sì, la politica di questo sito consente `unsafe-inline` e `unsafe-eval` negli script — è una debolezza reale, ereditata dal modo in cui vengono caricati alcuni script terzi, ed è proprio il meccanismo attraverso cui il nostro audit di accessibilità ha iniettato uno strumento di verifica nella pagina di produzione. Su un progetto in cui la restrizione la poniamo noi dall’inizio, la forma corretta è quella della piattaforma di segnalazioni: valore unico per risposta generato nel proxy e nessuna fonte terza per gli script. La differenza tra le due è esattamente la discussione che dovremmo avere all’inizio di un progetto, non alla fine.
Come verifico, senza fidarmi della vostra parola, che la limitazione di tasso funziona?
Inviando dodici richieste consecutive a un percorso di interfaccia di programmazione di questo sito e contando le risposte: le prime nove passano, la decima riceve 429 con l’intestazione che indica dopo quanto tempo si può riprovare. La finestra è di un minuto. Il comando è nell’elenco delle sorgenti di questa pagina e potete eseguirlo ora. Lo stesso principio lo applichiamo a ciò che consegniamo: se un controllo non può essere verificato dall’esterno dal cliente, non viene consegnato, viene dichiarato.
Cosa succede ai dati personali di un modulo?
Vengono scritti in un registro con aggiunta, un oggetto per riga, con diritti limitati su file e directory, prima di tentare la consegna — così un canale di notifica guasto non fa sparire la richiesta. L’indirizzo IP viene troncato al prefisso di rete prima della scrittura. I file più vecchi del termine dichiarato vengono eliminati, con il numero di giorni preso dallo stesso valore che appare nella politica pubblicata. E la riga nel registro dei trattamenti indica, per ogni elemento, in quale file del codice è implementato.
Potete fare autenticazione con identità elettronica di Stato o firma elettronica?
Il codice esiste ed è testato, ma non è attivato in alcun luogo in produzione, e la differenza conta. Abbiamo scritto un fornitore di servizi per l’autenticazione federata e un client di firma, entrambi senza nuove dipendenze, con le difese specifiche implementate e con test. Ciò che manca non riguarda il codice: contratto con l’autorità, certificato di sistema e registrazione dell’indirizzo di produzione. Fino ad allora, la variante che funziona oggi è quella in cui il cittadino firma sul portale ufficiale e carica indietro il documento firmato.
Quali controlli inserite normalmente in una nuova applicazione?
Intestazioni e politica dei contenuti con valore unico per risposta; limitazione di tasso con la chiave presa correttamente da dietro il proxy; separazione per organizzazione applicata nel database, non solo nell’applicazione; segreti crittografati e mai nelle risposte o nei registri; chiavi di idempotenza sugli eventi di terzi; autenticazione in due passaggi obbligatoria per gli account del personale; registro di audit con visibilità separata per interno e pubblico; e, per i progetti pubblici, una lista bianca di destinazioni di rete verificata automaticamente a ogni consegna.
Che cosa non copre questo servizio?
La sicurezza della rete aziendale, le apparecchiature degli utenti, il monitoraggio continuo di tipo centro operativo, la risposta agli incidenti 24/7, l’investigazione forense e la formazione contro il phishing. Non sono cose che facciamo male — sono cose che non facciamo. Il nostro ambito è l’applicazione che costruiamo o prendiamo in carico, più i dati che vi passano attraverso.
Su cosa si basano le affermazioni sopra (24 fonti)
Header in produzione: HSTS 63072000 s con sottodomini e preload, content-type non deducibile, referrer policy restrittiva, permissions policy che chiude la fotocamera; l'incorporamento in frame è rifiutato completamente sulle rotte API e limitato alla stessa origine sulle paginehttps://www.megapromoting.com/api/health/contact · 2026-09-06
22 di esse sono codice e file dei nostri repository. Non ne pubblichiamo il nome né la riga: insieme, in un'unica pagina, descriverebbero con troppa precisione come sono costruiti sistemi che non sono solo nostri. Le esaminiamo con te, nel repository, su richiesta — la verifica resta possibile, solo che avviene in una discussione.