2IZI Guard · 0.4.10 · PRE-1.0

Documentation

Le core actuel cible PHP 8.1+ et reste indépendant du framework à la frontière de sécurité. Protégez chaque action explicitement et consommez le token avant l’opération métier.

Pour les actions applicatives

La sécurité est une décision serveur, pas un état de widget.

2IZI Guard protège les formulaires et actions publiques grâce à une évaluation locale du risque, une friction adaptative et des jetons serveur à usage unique. Aucun runtime CAPTCHA externe obligatoire.

PHP 8.1+Core runtime
MariaDB / MySQLBaseline storage
0required outbound runtime calls
256-bitopaque token entropy
PRE-1.0La branche actuelle a une architecture security-first et des tests regression/red-team automatisés. Déployez d’abord Shadow Mode puis calibrez l’enforcement sur le trafic réel.
Quick start

Petite surface d’intégration. L’autorisation finale reste côté serveur.

Le core actuel cible PHP 8.1+ et reste indépendant du framework à la frontière de sécurité. Protégez chaque action explicitement et consommez le token avant l’opération métier.

1. Frontend

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

2. Protected action

Action protégéePHP
$result = Guard::verifyAndConsume(
    $_POST['guard_token'] ?? '',
    'contact'
);

if (!$result->allowed()) {
    http_response_code(403);
    exit;
}

Actions typiques

loginregisterpassword_resetcontactcheckoutfile_upload
Server authorityUn succès JavaScript n’est jamais une autorisation. Le serveur vérifie et consomme le token Guard.
Fonctionnement

Une action protégée. Cinq contrôles indépendants.

Le navigateur peut participer à la challenge, mais la permission métier est toujours émise et consommée par le serveur.

01

Valider le contexte

Vérifier Origin, action, session et limites grossières avant les opérations coûteuses.

02

Évaluer localement

Les signaux serveur et applicatifs produisent une décision de risque explicable.

03

Ajouter de la friction

La policy choisit PASS, PoW, interaction, throttle ou deny.

04

Émettre une fois

Lier un token opaque aléatoire 256-bit à session/action/origin et un TTL court.

05

Consommer atomiquement

L’endpoint métier consomme une fois; replay, mismatch et expiration sont refusés.

Policy modes

ShadowObserve and predict; no enforcement.
InvisibleNo visible challenge.
AdaptiveRisk-based PASS / PoW / interaction / deny.
Always challengeRequire step-up for every protected request.

Le trafic de confiance peut passer silencieusement; un risque élevé peut déclencher PoW, maintien, limitation ou refus.

Intégration

Integration contract

Le core actuel cible PHP 8.1+ et reste indépendant du framework à la frontière de sécurité. Protégez chaque action explicitement et consommez le token avant l’opération métier.

Action registry

The server defines allowed action names. Never use a client-provided action as authorization context.

'contact' => [
  'mode' => 'adaptive',
  'fail_mode' => 'open_with_limit'
]

Origin / session binding

tokens opaques 256-bit · stockage hash uniquement · TTL court · liaison action/session/origin · intégrité HMAC · consommation atomique unique · signaux métier server-only · fail-closed pour actions critiques.

UI isolation

Shadow DOM isolates Guard visuals from host CSS. It is a UI reliability layer, not a security boundary.

Localization

UI locale is BCP-47-style, UTF-8, RTL-ready, touch/keyboard compatible, and extendable with locale packs.

Modèle de menace

Nous supposons que l’attaquant connaît tout le code.

Le code, JavaScript, l’API, le schéma DB, PoW et les seuils peuvent être connus. Les secrets et l’autorisation restent côté serveur.

Nous supposons que l’attaquant possède

  • le code source complet
  • des modèles AI modernes
  • Playwright / Selenium / headless Chromium
  • des proxies résidentiels
  • des captures de son propre trafic

La sécurité ne repose pas sur la dissimulation de

  • JavaScript
  • algorithmes de challenge
  • noms de champs
  • endpoints
  • seuils de risque
Invariants principauxtokens opaques 256-bit · stockage hash uniquement · TTL court · liaison action/session/origin · intégrité HMAC · consommation atomique unique · signaux métier server-only · fail-closed pour actions critiques.
Limite assuméeAucune challenge navigateur ne peut prouver mathématiquement « humain biologique ». Les actions critiques nécessitent toujours passkey/WebAuthn, MFA, comptes vérifiés, autorisation de transaction et limites métier.
Open source

Le code public doit améliorer l’audit, pas affaiblir le modèle.

Lire l’implémentation ne doit pas créer de bypass d’autorisation. La revue publique exige releases, clés, droits du dépôt et traitement des vulnérabilités rigoureux.

Publier

  • source et historique
  • SECURITY.md et responsible disclosure
  • threat model et architecture
  • tests security / red-team automatisés
  • checksums et release notes

Garder privé

  • production config/guard.php
  • APP_KEY et clés HMAC/privacy/rate-limit
  • dumps DB et vrais security events
  • vrais cookies, tokens et sessions
  • secrets de déploiement et détails privés
Operations

Diagnostics, tests and updates

Diagnostics

php bin/diagnose.php

Check database state, key material, Origin configuration and registered actions before enabling enforcement.

Regression / red-team

bash tests/run-all.sh

Release acceptance includes replay, proxy, risk, tampering, UI and integration checks. Run disposable MariaDB/MySQL concurrency tests where available.

Updates

Read release notes and migrations first. Do not overwrite production config/guard.php with a distribution template. Rotate keys only when a release explicitly requires it.

Rollout

Start with Shadow Mode, review predicted decisions and false positives, tune action policies, then enable calibrated enforcement.

État actuel

0.4.10 · pre-1.0 · développement actif

La branche actuelle a une architecture security-first et des tests regression/red-team automatisés. Déployez d’abord Shadow Mode puis calibrez l’enforcement sur le trafic réel.

PHP coreDisponible
Webasyst / Shop-Script adapterAprès stabilisation du core
Verified agents / Privacy PassFutur / dépend des standards
0.4.10The responsive-layout hotfix changes UI sizing and preview embedding only; database schema, token/challenge protocol, keys, risk engine and server authorization logic are unchanged.

Langue

EnglishEnglishРусскийRussian简体中文Chinese (Simplified)繁體中文Chinese (Traditional)日本語Japanese한국어KoreanDeutschGermanFrançaisFrenchEspañolSpanishItalianoItalianPortuguês (Brasil)Portuguese (Brazil)العربيةArabicעבריתHebrewTürkçeTurkishPolskiPolishNederlandsDutchBahasa IndonesiaIndonesianTiếng ViệtVietnameseहिन्दीHindiPortuguês (Portugal)Portuguese (Portugal)ČeštinaCzechRomânăRomanianMagyarHungarianΕλληνικάGreekSvenskaSwedishNorskNorwegianDanskDanishSuomiFinnishไทยThai