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 utilização única. 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 o estado de um widget.

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

Local por defeito

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

Autoridade do servidor

Sucesso de JavaScript não é autorização. O servidor valida e consome o token Guard.

Fricção adaptativa

Tráfego fiável pode passar sem fricção; risco maior pode ativar PoW, hold, throttle ou deny.

Velocity-aware

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

Privacy-first

IP e sinais do browser não são identidade; fingerprinting invasivo está desativado por defeito.

Decisões explicáveis

Risk Engine guarda reason codes e previsões Shadow Mode para afinação.

Como funciona

Uma action protegida. Cinco pontos de controlo independentes.

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

Validar contexto

Verificar Origin, action, session e limites básicos antes de trabalho dispendioso.

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 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 permanecem 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

A segurança não depende de esconder

JavaScript
algoritmos challenge
nomes de campos
endpoints
risk thresholds

Código aberto

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

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

Publicar

source e histórico de alterações
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
DB dumps e security events reais
cookies/tokens/sessions reais
segredos de deployment e infraestrutura privada

Integração

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

O core atual visa PHP 8.1+ e é framework-independent 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

Estado atual

0.4.10 · pre-1.0 · desenvolvimento ativo

O branch atual tem arquitetura security-first e cobertura regression/red-team automatizada. Comece por Shadow Mode e calibre enforcement com tráfego real.

PHP coreDisponível

Webasyst / Shop-Script adapterDepois de estabilizar o core

Verified agents / Privacy PassFuturo / depende de standards

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 a segurança não pode depender de obscurity. Review pública e tests ajudam a encontrar falhas mais cedo.

Guard substitui MFA, passkey ou WAF?+

Não. Guard é uma camada anti-automation / abuse-protection. Actions críticas continuam a exigir authentication, authorization, CSRF, MFA/passkey e controlos de infraestrutura.

O core precisa de Internet?+

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

Um bot avançado pode passar o controlo interativo?+

Sim. Browser controlado, AI ou human solver podem imitar interaction. A autorização final continua dependente de server context, limits, tokens e business policy.

Crie proteção contra abuso que pode auditar.

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

Abrir repositório Documentação