Security is a server decision, not a widget state.
2IZI Guard protects forms and public actions with local risk evaluation, adaptive friction, and single-use server authorization tokens. No mandatory external CAPTCHA runtime.
Small integration surface. Final permission stays server-side.
The current core targets PHP 8.1+ and is framework-independent at the security boundary. Protect each action explicitly and consume the token before running the business operation.
1. Frontend
<script src="/guard/public/assets/guard.js?v=0.4.10" defer></script> <form data-guard-action="contact"> … </form>
2. Protected action
$result = Guard::verifyAndConsume(
$_POST['guard_token'] ?? '',
'contact'
);
if (!$result->allowed()) {
http_response_code(403);
exit;
}Typical actions
loginregisterpassword_resetcontactcheckoutfile_uploadOne protected action. Five independent checkpoints.
The browser can participate in the challenge, but permission to run the business action is always issued and consumed by the server.
Validate context
Origin, action, session and coarse limits are checked before expensive work.
Score locally
Server and application signals produce an explainable risk decision.
Add friction
The policy can choose PASS, Proof-of-Work, interaction, throttle or deny.
Issue once
A random 256-bit opaque token is bound to session, action, origin and a short TTL.
Consume atomically
The business endpoint consumes the token once; replay, mismatch and expiry are rejected.
Policy modes
Trusted traffic can pass silently. Higher risk can trigger Proof-of-Work, hold-to-confirm, throttling or denial.
Integration contract
The current core targets PHP 8.1+ and is framework-independent at the security boundary. Protect each action explicitly and consume the token before running the 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 token storage · short TTL · action/session/origin binding · HMAC integrity · single-use 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.
Assume the attacker knows the entire codebase.
2IZI Guard follows a Kerckhoffs-style assumption: source code, JavaScript, API contract, database schema, PoW algorithm and thresholds may be known. Security must still hold because secrets and authorization remain server-side.
Assume the attacker has
- full source code
- modern AI models
- Playwright / Selenium / headless Chromium
- residential proxies
- captures of their own traffic
Security does not rely on hiding
- JavaScript
- challenge algorithms
- field names
- endpoints
- risk thresholds
Public code should increase scrutiny, not weaken the model.
Reading the implementation must not create an authorization bypass. Public review is useful when releases, keys, repository permissions and vulnerability handling are disciplined.
Publish
- source and change history
- SECURITY.md and responsible disclosure
- threat model and architecture
- automated security / red-team tests
- release checksums and notes
Keep private
- production config/guard.php
- APP_KEY and HMAC/privacy/rate-limit keys
- database dumps and real security events
- real cookies, tokens and sessions
- deployment secrets and private infrastructure details
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.
0.4.10 · pre-1.0 · active development
The current branch has a security-first architecture and automated regression/red-team coverage. Deploy gradually: Shadow Mode first, then calibrated enforcement on real traffic.