SELF-HOSTED SECURITY · PRE-1.0

Bot-Schutz, bei dem die Vertrauensentscheidung auf Ihrem Server bleibt.

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

Dokumentation Quellcode

Keine verpflichtenden Google-, Yandex-, Cloudflare-, externen API-, CDN- oder Drittanbieter-Telemetrie-Abhängigkeiten im Core.

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

Für Anwendungsaktionen

Sicherheit ist eine Serverentscheidung, kein Widget-Zustand.

Eine sichtbare Challenge ist nur eine Schicht. Guard schützt die Serveraktion vor der Geschäftsoperation.

Lokal standardmäßig

Risikobewertung, Challenge-Prüfung und Autorisierung bleiben im Projekt.

Server entscheidet

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

Adaptive Reibung

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

Velocity-aware

Limits können Netzwerk, Guard-Session, Konto, Action und Site-Kontext kombinieren.

Privacy-first

IP und Browser-Signale gelten nicht als Identität; invasives Fingerprinting ist standardmäßig aus.

Erklärbare Entscheidungen

Risk Engine speichert Reason Codes und Shadow-Mode-Prognosen zur Kalibrierung.

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.

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

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

Integration

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.

loginregisterpassword_resetcontactcheckoutfile_upload

FrontendHTML

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

Geschützte ActionPHP

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

PRE-1.0

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

Release0.4.10

FAQ

Klare Aussagen. Klare Grenzen.

Macht öffentlicher Source Guard leichter angreifbar?+

Er macht die Implementierung leichter analysierbar. Genau deshalb darf Sicherheit nicht auf Obscurity beruhen. Öffentliche Reviews und Tests können Fehler früher finden.

Ersetzt Guard MFA, Passkeys oder WAF?+

Nein. Guard ist eine Anti-Automation-/Abuse-Schicht. Kritische Aktionen benötigen weiterhin Authentifizierung, Autorisierung, CSRF, MFA/Passkeys und Infrastrukturkontrollen.

Braucht der Core Internet?+

Der Kernschutz benötigt keine verpflichtenden Outbound Requests. Updates, Repository und optionale Attestation sind getrennt.

Kann ein fortgeschrittener Bot die Interaktion bestehen?+

Ja. Controlled Browser, AI oder Human Solver können Interaktion imitieren. Finale Autorisierung hängt weiter von Server-Kontext, Limits, Token und Business-Policy ab.

Missbrauchsschutz, den Sie prüfen können.

Lokale Runtime. Server-Autorisierung. Öffentliches Bedrohungsmodell. Kein verpflichtendes externes CAPTCHA.

Repository öffnen Dokumentation