SEGURANÇA SELF-HOSTED · PRE-1.0

Proteção contra bots com a decisão de confiança mantida no seu servidor.

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.

Documentação Ver código

O core não exige Google, Yandex, Cloudflare, API externa, CDN ou telemetria de terceiros.

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

Para ações da aplicação

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

A challenge visível é apenas uma camada. Guard protege a ação do servidor antes da operação de negócio.

Local por padrão

Avaliação de risco, challenge e autorização ficam dentro do projeto.

Autoridade do servidor

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

Fricção adaptativa

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

Velocity-aware

Limites podem combinar rede, sessão Guard, conta, action e contexto global.

Privacy-first

IP e sinais do navegador não são identidade; fingerprinting invasivo fica desligado por padrão.

Decisões explicáveis

Risk Engine mantém reason codes e previsões Shadow Mode para tuning.

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.

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

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

Integração

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.

loginregisterpassword_resetcontactcheckoutfile_upload

FrontendHTML

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

Action protegidaPHP

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

PRE-1.0

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

Release0.4.10

FAQ

Afirmações claras. Limites claros.

Código público torna Guard mais fácil de quebrar?+

Torna a implementação mais fácil de estudar, por isso segurança não pode depender de obscurity. Review pública e testes ajudam a achar falhas antes.

Guard substitui MFA, passkey ou WAF?+

Não. Guard é uma camada anti-automation / abuse-protection. Actions críticas ainda exigem autenticação, autorização, CSRF, MFA/passkey e controles de infraestrutura.

O core precisa de Internet?+

O fluxo principal não exige outbound requests obrigatórios. Updates, repository e attestation opcional são separados.

Um bot avançado ainda pode passar o controle interativo?+

Sim. Browser controlado, AI ou solver humano podem imitar interação. A autorização final ainda depende de contexto servidor, limits, tokens e business policy.

Crie proteção contra abuso que você pode auditar.

Runtime local. Autorização no servidor. Modelo de ameaça público. Sem CAPTCHA externo obrigatório.

Abrir repositório Documentação