SICUREZZA SELF-HOSTED · PRE-1.0

Protezione dai bot con la decisione di fiducia che resta sul tuo server.

2IZI Guard protegge moduli e azioni pubbliche con valutazione locale del rischio, frizione adattiva e token server monouso. Nessun runtime CAPTCHA esterno obbligatorio.

Documentazione Codice sorgente

Il core non richiede Google, Yandex, Cloudflare, API esterne, CDN o telemetria di terze parti.

PHP 8.1+AdaptiveShadow ModePrivacy-first

2IZI Guardlocal decision surface

actionregister

origin2iziguard.com

sessionbound

modeAdaptive

local risk18/100

PASSsilent

Context

Risk

Challenge

Token

Consume

0required third-party calls

256-bitopaque token

HMACstate integrity

1×atomic consume

0required outbound runtime calls

256-bitopaque token entropy

3×action / session / origin bound

1×atomic one-time consume

Per le azioni applicative

La sicurezza è una decisione del server, non lo stato di un widget.

La challenge visibile è solo uno strato. Guard protegge l’azione server prima dell’operazione business.

Locale per impostazione

Valutazione del rischio, challenge e autorizzazione restano nel progetto.

Autorità server

Il successo JavaScript non è mai autorizzazione. Il server verifica e consuma il token Guard.

Friction adattiva

Traffico affidabile può passare in silenzio; rischio maggiore può attivare PoW, hold, throttle o deny.

Velocity-aware

I limiti possono combinare rete, sessione Guard, account, action e contesto globale.

Privacy-first

IP e segnali browser non sono identità; fingerprinting invasivo disattivato di default.

Decisioni spiegabili

Risk Engine conserva reason codes e previsioni Shadow Mode per il tuning.

Come funziona

Una action protetta. Cinque controlli indipendenti.

Il browser può partecipare alla challenge, ma il permesso business viene sempre emesso e consumato dal server.

Valida contesto

Controlla Origin, action, session e limiti base prima del lavoro costoso.

Valuta localmente

Segnali server e applicativi producono una decisione di rischio spiegabile.

Aggiunge friction

La policy sceglie PASS, PoW, interaction, throttle o deny.

Emette una volta

Token opaco casuale 256-bit legato a session/action/origin e TTL breve.

Consuma atomicamente

L’endpoint business consuma una volta; replay, mismatch e expiry vengono rifiutati.

Modello di minaccia

Assumiamo che l’attaccante conosca tutto il codice.

Codice, JavaScript, API, schema DB, PoW e soglie possono essere noti. Segreti e autorizzazione restano server-side.

Assumiamo che l’attaccante abbia

codice sorgente completo
modelli AI moderni
Playwright / Selenium / headless Chromium
proxy residenziali
catture del proprio traffico

La sicurezza non dipende dal nascondere

JavaScript
algoritmi challenge
nomi campi
endpoint
risk threshold

Open source

Il codice pubblico deve aumentare l’auditabilità, non indebolire il modello.

Leggere l’implementazione non deve creare bypass di autorizzazione. La review pubblica richiede release, chiavi, permessi repository e vulnerability handling disciplinati.

Pubblicare

sorgente e cronologia modifiche
SECURITY.md e responsible disclosure
threat model e architettura
test security / red-team automatici
checksum release e note

Tenere privato

production config/guard.php
APP_KEY e chiavi HMAC/privacy/rate-limit
dump DB e security events reali
cookie, token e sessioni reali
segreti deploy e infrastruttura privata

Integrazione

Superficie ridotta. Il permesso finale resta sul server.

Il core attuale punta a PHP 8.1+ ed è framework-independent al confine di sicurezza. Proteggi ogni action esplicitamente e consuma il token prima dell’operazione business.

loginregisterpassword_resetcontactcheckoutfile_upload

FrontendHTML

<script src="/guard/public/assets/guard.js" defer></script>
<form data-guard-action="contact">
  …
</form>

Action protettaPHP

$result = Guard::verifyAndConsume(
  $_POST['guard_token'] ?? '',
  'contact'
);
if (!$result->allowed()) { http_response_code(403); exit; }

PRE-1.0

Stato attuale

0.4.10 · pre-1.0 · sviluppo attivo

Il branch attuale ha architettura security-first e coverage automatica regression/red-team. Prima Shadow Mode, poi enforcement calibrato su traffico reale.

PHP coreDisponibile

Webasyst / Shop-Script adapterDopo stabilizzazione core

Verified agents / Privacy PassFuturo / dipende dagli standard

Release0.4.10

FAQ

Promesse chiare. Limiti chiari.

Il source pubblico rende Guard più facile da rompere?+

Rende più facile studiare l’implementazione, quindi la sicurezza non può dipendere dall’obscurity. Review pubbliche e test aiutano a trovare difetti prima.

Guard sostituisce MFA, passkey o WAF?+

No. Guard è un layer anti-automation / abuse-protection. Action critiche richiedono ancora autenticazione, autorizzazione, CSRF, MFA/passkey e controlli infrastrutturali.

Il core ha bisogno di Internet?+

Il flusso core non richiede richieste outbound obbligatorie. Updates, repository e attestation opzionale sono separati.

Un bot avanzato può superare il controllo interattivo?+

Sì. Browser controllati, AI o solver umani possono imitare l’interazione. L’autorizzazione finale dipende ancora da contesto server, limits, token e business policy.

Crea protezione dagli abusi che puoi verificare.

Runtime locale. Autorizzazione server. Threat model pubblico. Nessun CAPTCHA esterno obbligatorio.

Apri repository Documentazione