SELF-HOSTED SECURITY · PRE-1.0

Ochrona przed botami, w której decyzja o zaufaniu pozostaje na Twoim serwerze.

2IZI Guard chroni formularze i publiczne akcje przez lokalną ocenę ryzyka, adaptacyjne utrudnienie i jednorazowe tokeny autoryzacyjne serwera. Bez obowiązkowej zewnętrznej CAPTCHA.

Dokumentacja Kod źródłowy

Core runtime nie wymaga Google, Yandex, Cloudflare, zewnętrznego API, CDN ani telemetrii stron trzecich.

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

Dla akcji aplikacji

Bezpieczeństwo to decyzja serwera, nie stan widgetu.

Widoczny challenge to tylko jedna warstwa. Guard chroni akcję serwera przed operacją biznesową.

Lokalnie domyślnie

Ocena ryzyka, challenge i autoryzacja pozostają w projekcie.

Decyduje serwer

Sukces JavaScript nie jest autoryzacją. Serwer weryfikuje i zużywa token Guard.

Adaptacyjne utrudnienie

Zaufany ruch może przejść niewidocznie; większe ryzyko może uruchomić PoW, hold, throttle lub deny.

Velocity-aware

Limity mogą łączyć sieć, sesję Guard, konto, action i kontekst całej witryny.

Privacy-first

IP i sygnały przeglądarki nie są tożsamością; agresywny fingerprinting jest domyślnie wyłączony.

Wyjaśnialne decyzje

Risk Engine zapisuje reason codes i przewidywania Shadow Mode do strojenia.

Jak działa

Jedna chroniona action. Pięć niezależnych punktów kontroli.

Przeglądarka może uczestniczyć w challenge, ale zgoda biznesowa zawsze jest wydawana i zużywana przez serwer.

Sprawdź kontekst

Origin, action, session i limity przed kosztowną pracą.

Oceń lokalnie

Sygnały serwera i aplikacji tworzą wyjaśnialną decyzję ryzyka.

Dodaj utrudnienie

Policy wybiera PASS, PoW, interaction, throttle lub deny.

Wydaj raz

Losowy 256-bit opaque token związany z session/action/origin i krótkim TTL.

Zużyj atomowo

Endpoint biznesowy zużywa raz; replay, mismatch i expiry są odrzucane.

Model zagrożeń

Zakładamy, że atakujący zna cały kod.

Kod, JavaScript, API, schemat DB, PoW i progi mogą być znane; sekrety i autoryzacja pozostają po stronie serwera.

Zakładamy, że atakujący ma

pełny kod źródłowy
nowoczesne modele AI
Playwright / Selenium / headless Chromium
residential proxies
zapisy własnego ruchu

Bezpieczeństwo nie zależy od ukrywania

JavaScript
algorytmów challenge
nazw pól
endpointów
risk thresholds

Open source

Publiczny kod powinien zwiększać audytowalność, a nie osłabiać model.

Czytanie implementacji nie może tworzyć authorization bypass. Publiczny review wymaga zdyscyplinowanych releases, keys, repository permissions i vulnerability handling.

Publikować

source i historia zmian
SECURITY.md i responsible disclosure
threat model i architektura
automatyczne security / red-team tests
release checksum i notes

Zachować prywatne

production config/guard.php
APP_KEY i HMAC/privacy/rate-limit keys
DB dumps i real security events
real cookies/tokens/sessions
deployment secrets i private infrastructure

Integracja

Mała powierzchnia integracji. Ostateczna zgoda pozostaje na serwerze.

Obecny core celuje w PHP 8.1+ i jest framework-independent na granicy bezpieczeństwa. Chroń każdą action jawnie i zużyj token przed operacją biznesową.

loginregisterpassword_resetcontactcheckoutfile_upload

FrontendHTML

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

Chroniona actionPHP

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

PRE-1.0

Aktualny stan

0.4.10 · pre-1.0 · aktywny rozwój

Obecny branch ma security-first architecture i automatyczne regression/red-team coverage. Najpierw Shadow Mode, potem enforcement kalibrowany na realnym ruchu.

PHP coreDostępny

Webasyst / Shop-Script adapterPo stabilizacji core

Verified agents / Privacy PassPrzyszłość / zależne od standardów

Release0.4.10

FAQ

Jasne deklaracje. Jasne granice.

Czy publiczny source ułatwia złamanie Guard?+

Ułatwia analizę implementacji, dlatego bezpieczeństwo nie może zależeć od obscurity. Publiczny review i tests pomagają znaleźć błędy wcześniej.

Czy Guard zastępuje MFA, passkey lub WAF?+

Nie. Guard jest warstwą anti-automation / abuse-protection. Krytyczne działania nadal potrzebują authentication, authorization, CSRF, MFA/passkey i kontroli infrastruktury.

Czy core runtime potrzebuje Internetu?+

Główny przepływ ochrony nie wymaga obowiązkowych outbound requests. Updates, repository i optional attestation są osobne.

Czy zaawansowany bot może przejść interaktywną kontrolę?+

Tak. Controlled browser, AI lub human solver mogą imitować interaction. Finalna autoryzacja nadal zależy od server context, limits, tokens i business policy.

Buduj ochronę przed nadużyciami, którą można audytować.

Lokalny runtime. Autoryzacja serwerowa. Publiczny model zagrożeń. Bez obowiązkowej zewnętrznej CAPTCHA.

Otwórz repozytorium Dokumentacja