2IZI Guard — Dokumentasjon

For applikasjonshandlinger

Sikkerhet er en serverbeslutning, ikke en widgettilstand.

2IZI Guard beskytter skjemaer og offentlige handlinger med lokal risikovurdering, adaptiv friksjon og engangstoken fra serveren. Ingen obligatorisk ekstern CAPTCHA-runtime.

PHP 8.1+Core runtime

MariaDB / MySQLBaseline storage

0required outbound runtime calls

256-bitopaque token entropy

PRE-1.0Nåværende branch har security-first architecture og automatisk regression/red-team coverage. Start med Shadow Mode og kalibrer enforcement på ekte trafikk.

Quick start

Liten integrasjonsflate. Endelig tillatelse blir server-side.

Nåværende core retter seg mot PHP 8.1+ og er framework-independent ved security boundary. Beskytt hver action eksplisitt og konsumer token før business operation.

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

Beskyttet actionPHP

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

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

Typiske actions

loginregisterpassword_resetcontactcheckoutfile_upload

Server authorityJavaScript-suksess er ikke autorisasjon. Serveren verifiserer og konsumerer Guard-token.

Slik fungerer det

Én beskyttet action. Fem uavhengige checkpoints.

Browseren kan delta i challenge, men business permission utstedes og konsumeres alltid av serveren.

Valider context

Kontroller Origin, action, session og grunnleggende limits før dyrt arbeid.

Vurder lokalt

Server- og applikasjonssignaler gir en forklarbar risikobeslutning.

Legg til friksjon

Policy velger PASS, PoW, interaction, throttle eller deny.

Utsted én gang

Tilfeldig 256-bit opaque token bindes til session/action/origin og kort TTL.

Konsumer atomisk

Business endpoint konsumerer én gang; replay, mismatch og expiry avvises.

Policy modes

ShadowObserve and predict; no enforcement.

InvisibleNo visible challenge.

AdaptiveRisk-based PASS / PoW / interaction / deny.

Always challengeRequire step-up for every protected request.

Betrodd trafikk kan passere stille; høyere risiko kan utløse PoW, hold, throttle eller deny.

Integrasjon

Integration contract

Nåværende core retter seg mot PHP 8.1+ og er framework-independent ved security boundary. Beskytt hver action eksplisitt og konsumer token før business operation.

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 · hash-only storage · kort TTL · binding action/session/origin · HMAC integrity · one-time atomic consume · server-only business signals · fail-closed critical 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.

Trusselmodell

Vi antar at angriperen kjenner hele kodebasen.

Kode, JavaScript, API, DB-skjema, PoW og terskler kan være kjent; hemmeligheter og autorisasjon forblir på serveren.

Vi antar at angriperen har

full source code
moderne AI-modeller
Playwright / Selenium / headless Chromium
residential proxies
captures av egen trafikk

Security avhenger ikke av å skjule

JavaScript
challenge algorithms
field names
endpoints
risk thresholds

Core invariants256-bit opaque tokens · hash-only storage · kort TTL · binding action/session/origin · HMAC integrity · one-time atomic consume · server-only business signals · fail-closed critical actions.

Ærlig begrensningIngen browser challenge kan matematisk bevise “biologisk menneske”. Critical actions trenger fortsatt passkey/WebAuthn, MFA, verified accounts, transaction authorization og business limits.

Åpen kildekode

Offentlig kode skal øke etterprøvbarheten, ikke svekke modellen.

Å lese implementation skal ikke skape authorization bypass. Public review krever disiplinerte releases, keys, repository permissions og vulnerability handling.

Publiser

source og endringshistorikk
SECURITY.md og responsible disclosure
threat model og architecture
automatiserte security / red-team tests
release checksums og notes

Hold privat

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

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.

Nåværende status

0.4.10 · pre-1.0 · aktiv utvikling

Nåværende branch har security-first architecture og automatisk regression/red-team coverage. Start med Shadow Mode og kalibrer enforcement på ekte trafikk.

PHP coreTilgjengelig

Webasyst / Shop-Script adapterEtter core-stabilisering

Verified agents / Privacy PassFremtid / standardavhengig

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.