La nostra base WAF e OWASP, spiegata
La sicurezza non dovrebbe essere un progetto da iniziare dopo il lancio. Su ogni istanza Clonext, un web application firewall gestito e una base allineata a OWASP sono attivi dal primo deploy — ecco cosa include concretamente.
Cosa blocca il WAF
All'edge, Google Cloud Armor filtra ogni richiesta prima che raggiunga la tua applicazione — una policy gestita sul load balancer globale di Google, così il tuo codice non deve mai essere l'ultima linea di difesa.
- I pattern dell'OWASP Top 10 — un guard applicato contro i classici payload di injection e cross-site scripting, con i set di regole OWASP preconfigurati che valutano ogni richiesta.
- Limiti di frequenza al login, all'edge e nell'applicazione — i tentativi ripetuti vengono bloccati prima di diventare forza bruta.
- Eccezioni progettate per rotta — i webhook di pagamento e gli editor avanzati continuano a funzionare; nulla viene bloccato per sbaglio.
- TLS con certificati gestiti da Google e HSTS, sul tuo dominio.
Una buona base è la sicurezza che ottieni senza aprire un ticket per averla.
OWASP come pavimento, non come soffitto
Gli standard OWASP ci danno una checklist comune, ma una checklist è un punto di partenza. Mappiamo ogni controllo su qualcosa di concreto nel core — gestione delle sessioni, encoding dell’output, politica delle dipendenze — e lo verifichiamo nel build, invece di fidarci che un framework l’abbia fatto per noi.
Tarato per istanza
Siccome ogni istanza è isolata, possiamo tarare le regole sul tuo traffico senza preoccuparci di un vicino. Un falso positivo sulla tua API viene sistemato per te — non negoziato attraverso una tenancy condivisa.
L'edge completo attorno a questa base — il bilanciatore globale, DNSSEC, la porta a identità — è raccontato in L'edge di Google, spiegato.
