2IZI Guard — Dokumentation

Für Anwendungsaktionen

Sicherheit ist eine Serverentscheidung, kein Widget-Zustand.

2IZI Guard schützt Formulare und öffentliche Aktionen mit lokaler Risikobewertung, adaptiver Reibung und einmaligen Server-Autorisierungstoken. Kein verpflichtendes externes CAPTCHA-Runtime.

PHP 8.1+Core runtime

MariaDB / MySQLBaseline storage

0required outbound runtime calls

256-bitopaque token entropy

PRE-1.0Der aktuelle Branch hat Security-first-Architektur und automatisierte Regression-/Red-Team-Tests. Erst Shadow Mode, danach Enforcement mit realem Traffic kalibrieren.

Quick start

Kleine Integrationsfläche. Die finale Freigabe bleibt serverseitig.

Der aktuelle Core zielt auf PHP 8.1+ und ist an der Sicherheitsgrenze framework-unabhängig. Jede Action wird explizit geschützt; Token vor der Business-Operation verbrauchen.

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

Geschützte ActionPHP

$result = Guard::verifyAndConsume(
    $_POST['guard_token'] ?? '',
    'contact'
);

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

Typische Actions

loginregisterpassword_resetcontactcheckoutfile_upload

Server authorityJavaScript-Erfolg ist keine Autorisierung. Der Endpoint prüft und verbraucht das Guard-Token serverseitig.

So funktioniert es

Eine geschützte Action. Fünf unabhängige Prüfpunkte.

Der Browser kann an der Challenge teilnehmen, doch Berechtigung wird immer serverseitig ausgestellt und verbraucht.

Kontext prüfen

Origin, Action, Session und grobe Limits vor teurer Arbeit prüfen.

Lokal bewerten

Server- und Anwendungssignale erzeugen eine erklärbare Risikoentscheidung.

Reibung hinzufügen

Policy wählt PASS, PoW, Interaktion, Throttle oder Deny.

Einmal ausstellen

Zufälliges 256-bit opaque Token an Session/Action/Origin und kurze TTL binden.

Atomar verbrauchen

Business-Endpoint verbraucht einmal; Replay, Mismatch und Ablauf werden abgelehnt.

Policy modes

ShadowObserve and predict; no enforcement.

InvisibleNo visible challenge.

AdaptiveRisk-based PASS / PoW / interaction / deny.

Always challengeRequire step-up for every protected request.

Vertrauenswürdiger Traffic kann still passieren; höheres Risiko kann PoW, Hold, Throttling oder Deny auslösen.

Integration

Integration contract

Der aktuelle Core zielt auf PHP 8.1+ und ist an der Sicherheitsgrenze framework-unabhängig. Jede Action wird explizit geschützt; Token vor der Business-Operation verbrauchen.

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

256-bit opaque Tokens · nur Hash-Speicherung · kurze TTL · Action/Session/Origin-Bindung · HMAC-Integrität · einmaliger atomarer Consume · server-only Business-Signale · fail-closed für kritische Actions.

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.

Bedrohungsmodell

Wir nehmen an, dass der Angreifer den gesamten Code kennt.

Quellcode, JavaScript, API, DB-Schema, PoW und Schwellenwerte dürfen bekannt sein. Geheimnisse und Autorisierung bleiben serverseitig.

Wir nehmen an, der Angreifer hat

vollständigen Quellcode
moderne AI-Modelle
Playwright / Selenium / headless Chromium
Residential Proxies
Mitschnitte des eigenen Traffics

Sicherheit beruht nicht auf Verbergen von

JavaScript
Challenge-Algorithmen
Feldnamen
Endpoints
Risikoschwellen

Kerninvarianten256-bit opaque Tokens · nur Hash-Speicherung · kurze TTL · Action/Session/Origin-Bindung · HMAC-Integrität · einmaliger atomarer Consume · server-only Business-Signale · fail-closed für kritische Actions.

Ehrliche GrenzeKeine Browser-Challenge kann „biologisch menschlich“ mathematisch beweisen. Kritische Actions benötigen weiterhin Passkey/WebAuthn, MFA, verifizierte Konten, Transaktionsfreigabe und Business-Limits.

Open Source

Öffentlicher Code soll die Prüfbarkeit erhöhen, nicht das Modell schwächen.

Das Lesen der Implementierung darf keinen Authorization-Bypass erzeugen. Öffentliche Prüfung braucht disziplinierte Releases, Keys, Repository-Rechte und Vulnerability Handling.

Veröffentlichen

Quellcode und Änderungshistorie
SECURITY.md und Responsible Disclosure
Threat Model und Architektur
automatisierte Security-/Red-Team-Tests
Release-Checksums und Notes

Privat halten

production config/guard.php
APP_KEY und HMAC/privacy/rate-limit keys
DB-Dumps und echte Security Events
echte Cookies, Tokens und Sessions
Deployment-Secrets und private Infrastrukturdetails

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.

Aktueller Stand

0.4.10 · pre-1.0 · aktive Entwicklung

Der aktuelle Branch hat Security-first-Architektur und automatisierte Regression-/Red-Team-Tests. Erst Shadow Mode, danach Enforcement mit realem Traffic kalibrieren.

PHP coreVerfügbar

Webasyst / Shop-Script adapterNach Core-Stabilisierung

Verified agents / Privacy PassZukunft / standardabhängig

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.