2IZI Guard · 0.4.10 · PRE-1.0

Documentación

El core actual apunta a PHP 8.1+ y es independiente del framework en la frontera de seguridad. Protege cada action explícitamente y consume el token antes de la operación de negocio.

Protección de acciones

La seguridad es una decisión del servidor, no el estado de un widget.

2IZI Guard protege formularios y acciones públicas con evaluación local de riesgo, fricción adaptativa y tokens de autorización de un solo uso. Sin runtime CAPTCHA externo obligatorio.

PHP 8.1+Core runtime
MariaDB / MySQLBaseline storage
0required outbound runtime calls
256-bitopaque token entropy
PRE-1.0La rama actual tiene arquitectura security-first y cobertura automatizada regression/red-team. Despliega primero Shadow Mode y calibra enforcement con tráfico real.
Quick start

Superficie pequeña. La autorización final permanece en el servidor.

El core actual apunta a PHP 8.1+ y es independiente del framework en la frontera de seguridad. Protege cada action explícitamente y consume el token antes de la operación de negocio.

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

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

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

Actions típicas

loginregisterpassword_resetcontactcheckoutfile_upload
Server authorityEl éxito de JavaScript nunca es autorización. El servidor verifica y consume el token Guard.
Cómo funciona

Una acción protegida. Cinco controles independientes.

El navegador puede participar en la challenge, pero el permiso de negocio siempre lo emite y consume el servidor.

01

Validar contexto

Comprobar Origin, action, session y límites básicos antes del trabajo costoso.

02

Evaluar localmente

Señales del servidor y aplicación producen una decisión de riesgo explicable.

03

Añadir fricción

La policy elige PASS, PoW, interacción, throttle o deny.

04

Emitir una vez

Token opaco aleatorio de 256-bit ligado a session/action/origin y TTL corto.

05

Consumir atómicamente

El endpoint de negocio consume una vez; replay, mismatch y expiry se rechazan.

Policy modes

ShadowObserve and predict; no enforcement.
InvisibleNo visible challenge.
AdaptiveRisk-based PASS / PoW / interaction / deny.
Always challengeRequire step-up for every protected request.

El tráfico confiable puede pasar en silencio; más riesgo puede activar PoW, mantener pulsado, throttle o deny.

Integración

Integration contract

El core actual apunta a PHP 8.1+ y es independiente del framework en la frontera de seguridad. Protege cada action explícitamente y consume el token antes de la operación de negocio.

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 · almacenamiento solo hash · TTL corto · binding action/session/origin · integridad HMAC · consumo atómico único · señales de negocio solo servidor · fail-closed en acciones 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 amenaza

Suponemos que el atacante conoce todo el código.

Código, JavaScript, API, esquema DB, PoW y umbrales pueden ser conocidos. Los secretos y la autorización permanecen en el servidor.

Suponemos que el atacante tiene

  • código fuente completo
  • modelos AI modernos
  • Playwright / Selenium / headless Chromium
  • proxies residenciales
  • capturas de su propio tráfico

La seguridad no depende de ocultar

  • JavaScript
  • algoritmos challenge
  • nombres de campos
  • endpoints
  • umbrales de riesgo
Invariantes principalestokens opacos 256-bit · almacenamiento solo hash · TTL corto · binding action/session/origin · integridad HMAC · consumo atómico único · señales de negocio solo servidor · fail-closed en acciones críticas.
Límite honestoNinguna challenge de navegador puede probar matemáticamente “humano biológico”. Las acciones críticas siguen necesitando passkey/WebAuthn, MFA, cuentas verificadas, autorización de transacción y límites de negocio.
Código abierto

El código público debe aumentar la auditabilidad, no debilitar el modelo.

Leer la implementación no debe producir un bypass de autorización. La revisión pública exige releases, claves, permisos de repositorio y gestión de vulnerabilidades disciplinados.

Publicar

  • código e historial de cambios
  • SECURITY.md y responsible disclosure
  • threat model y arquitectura
  • tests security / red-team automatizados
  • checksums y release notes

Mantener privado

  • production config/guard.php
  • APP_KEY y claves HMAC/privacy/rate-limit
  • dumps DB y security events reales
  • cookies, tokens y sessions reales
  • secretos de despliegue e infraestructura 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.

Estado actual

0.4.10 · pre-1.0 · desarrollo activo

La rama actual tiene arquitectura security-first y cobertura automatizada regression/red-team. Despliega primero Shadow Mode y calibra enforcement con tráfico real.

PHP coreDisponible
Webasyst / Shop-Script adapterDespués de estabilizar el core
Verified agents / Privacy PassFuturo / depende de estándares
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.

Idioma

EnglishEnglishРусскийRussian简体中文Chinese (Simplified)繁體中文Chinese (Traditional)日本語Japanese한국어KoreanDeutschGermanFrançaisFrenchEspañolSpanishItalianoItalianPortuguês (Brasil)Portuguese (Brazil)العربيةArabicעבריתHebrewTürkçeTurkishPolskiPolishNederlandsDutchBahasa IndonesiaIndonesianTiếng ViệtVietnameseहिन्दीHindiPortuguês (Portugal)Portuguese (Portugal)ČeštinaCzechRomânăRomanianMagyarHungarianΕλληνικάGreekSvenskaSwedishNorskNorwegianDanskDanishSuomiFinnishไทยThai