2IZI Guard — Documentação

Para ações da aplicação

Segurança é uma decisão do servidor, não um estado do widget.

2IZI Guard protege formulários e ações públicas com avaliação local de risco, fricção adaptativa e tokens de autorização de uso único. Sem runtime CAPTCHA externo obrigatório.

PHP 8.1+Core runtime

MariaDB / MySQLBaseline storage

0required outbound runtime calls

256-bitopaque token entropy

PRE-1.0O branch atual tem arquitetura security-first e cobertura automatizada regression/red-team. Primeiro Shadow Mode, depois enforcement calibrado com tráfego real.

Quick start

Superfície pequena. A autorização final fica no servidor.

O core atual mira PHP 8.1+ e é independente de framework na fronteira de segurança. Proteja cada action explicitamente e consuma o token antes da operação business.

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

Action protegidaPHP

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

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

Actions típicas

loginregisterpassword_resetcontactcheckoutfile_upload

Server authoritySucesso no JavaScript nunca é autorização. O servidor verifica e consome o token Guard.

Como funciona

Uma action protegida. Cinco checkpoints independentes.

O navegador pode participar do challenge, mas a permissão de negócio é sempre emitida e consumida pelo servidor.

Validar contexto

Checar Origin, action, session e limites básicos antes do trabalho caro.

Avaliar localmente

Sinais do servidor e aplicação produzem uma decisão de risco explicável.

Adicionar fricção

A policy escolhe PASS, PoW, interaction, throttle ou deny.

Emitir uma vez

Token opaco aleatório de 256-bit ligado a session/action/origin e TTL curto.

Consumir atomicamente

O endpoint de negócio consome uma vez; replay, mismatch e expiry são rejeitados.

Policy modes

ShadowObserve and predict; no enforcement.

InvisibleNo visible challenge.

AdaptiveRisk-based PASS / PoW / interaction / deny.

Always challengeRequire step-up for every protected request.

Tráfego confiável pode passar silenciosamente; maior risco pode acionar PoW, hold, throttle ou deny.

Integração

Integration contract

O core atual mira PHP 8.1+ e é independente de framework na fronteira de segurança. Proteja cada action explicitamente e consuma o token antes da operação business.

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

tokens opacos 256-bit · armazenamento só de hash · TTL curto · binding action/session/origin · integridade HMAC · consume atômico único · sinais business só do servidor · fail-closed em actions críticas.

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.

Modelo de ameaça

Assumimos que o atacante conhece todo o código.

Código, JavaScript, API, esquema DB, PoW e limites podem ser conhecidos. Segredos e autorização continuam no servidor.

Assumimos que o atacante tem

código-fonte completo
modelos AI modernos
Playwright / Selenium / headless Chromium
proxies residenciais
capturas do próprio tráfego

Segurança não depende de esconder

JavaScript
algoritmos challenge
nomes de campos
endpoints
risk thresholds

Invariantes centraistokens opacos 256-bit · armazenamento só de hash · TTL curto · binding action/session/origin · integridade HMAC · consume atômico único · sinais business só do servidor · fail-closed em actions críticas.

Limite honestoNenhum challenge de navegador prova matematicamente “humano biológico”. Actions críticas ainda precisam de passkey/WebAuthn, MFA, contas verificadas, autorização de transação e limites de negócio.

Código aberto

Código público deve aumentar a auditabilidade, não enfraquecer o modelo.

Ler a implementação não deve criar bypass de autorização. Revisão pública exige releases, chaves, permissões de repository e vulnerability handling disciplinados.

Publicar

source e histórico de mudanças
SECURITY.md e responsible disclosure
threat model e arquitetura
tests security / red-team automatizados
checksums e release notes

Manter privado

production config/guard.php
APP_KEY e chaves HMAC/privacy/rate-limit
dumps DB e security events reais
cookies, tokens e sessions reais
segredos de deploy e infraestrutura privada

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.

Status atual

0.4.10 · pre-1.0 · desenvolvimento ativo

O branch atual tem arquitetura security-first e cobertura automatizada regression/red-team. Primeiro Shadow Mode, depois enforcement calibrado com tráfego real.

PHP coreDisponível

Webasyst / Shop-Script adapterDepois da estabilização do core

Verified agents / Privacy PassFuturo / depende de padrões

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.