SÉCURITÉ AUTO-HÉBERGÉE · PRE-1.0

Protection anti-bot dont la décision de confiance reste sur votre serveur.

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.

Documentation Code source

Aucune dépendance obligatoire à Google, Yandex, Cloudflare, API externe, CDN ou télémétrie tierce dans le cœur.

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

Pour les actions applicatives

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

La challenge visible n’est qu’une couche. Guard protège l’action serveur avant l’opération métier.

Local par défaut

Évaluation du risque, challenge et autorisation restent dans votre projet.

Autorité serveur

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

Friction adaptative

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

Velocity-aware

Les limites peuvent combiner réseau, session Guard, compte, action et contexte global du site.

Privacy-first

IP et signaux navigateur ne sont pas une identité; le fingerprinting invasif est désactivé par défaut.

Décisions explicables

Risk Engine conserve reason codes et prédictions Shadow Mode pour le réglage.

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.

Valider le contexte

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

Évaluer localement

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

Ajouter de la friction

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

Émettre une fois

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

Consommer atomiquement

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

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

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

Intégration

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.

loginregisterpassword_resetcontactcheckoutfile_upload

FrontendHTML

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

Action protégéePHP

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

PRE-1.0

É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

Release0.4.10

FAQ

Promesses claires. Limites claires.

Le source public rend-il Guard plus facile à casser ?+

Il rend l’implémentation plus facile à étudier, donc la sécurité ne doit pas dépendre de l’obscurité. Revues publiques et tests peuvent trouver les défauts plus tôt.

Guard remplace-t-il MFA, passkeys ou WAF ?+

Non. Guard est une couche anti-automation et abuse protection. Les actions critiques gardent besoin d’authentification, autorisation, CSRF, MFA/passkeys et contrôles d’infrastructure.

Le core a-t-il besoin d’Internet ?+

Le flux de protection principal n’exige aucune requête sortante obligatoire. Updates, repository et attestation optionnelle sont séparés.

Un bot avancé peut-il passer le contrôle interactif ?+

Oui. Browser contrôlé, AI ou solver humain peuvent imiter l’interaction. L’autorisation finale dépend toujours du contexte serveur, des limites, tokens et politiques métier.

Construisez une protection contre les abus que vous pouvez auditer.

Runtime local. Autorisation serveur. Modèle de menace public. Aucun CAPTCHA externe obligatoire.

Ouvrir le dépôt Documentation