Local por defecto
La evaluación de riesgo, challenge y autorización permanecen dentro del proyecto.
SEGURIDAD AUTOALOJADA · PRE-1.0
Protección contra bots donde la decisión de confianza permanece en tu servidor.
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.
El núcleo no requiere Google, Yandex, Cloudflare, API externa, CDN ni telemetría de terceros.
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
Protección de acciones
La seguridad es una decisión del servidor, no el estado de un widget.
La challenge visible es solo una capa. Guard protege la acción del servidor antes de la operación de negocio.
Autoridad del servidor
El éxito de JavaScript nunca es autorización. El servidor verifica y consume el token Guard.
Fricción adaptativa
El tráfico confiable puede pasar en silencio; más riesgo puede activar PoW, mantener pulsado, throttle o deny.
Velocity-aware
Los límites pueden combinar red, sesión Guard, cuenta, action y contexto global.
Privacy-first
IP y señales del navegador no son identidad; el fingerprinting invasivo está desactivado por defecto.
Decisiones explicables
Risk Engine conserva reason codes y predicciones Shadow Mode para ajustar.
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.
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
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
Integración
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.
Actions típicasloginregisterpassword_resetcontactcheckoutfile_upload
FrontendHTML
<script src="/guard/public/assets/guard.js" defer></script> <form data-guard-action="contact"> … </form>
Acción protegidaPHP
$result = Guard::verifyAndConsume( $_POST['guard_token'] ?? '', 'contact' ); if (!$result->allowed()) { http_response_code(403); exit; }
PRE-1.0
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
Release0.4.10
FAQ
Afirmaciones claras. Límites claros.
¿El código público hace Guard más fácil de romper?+
Hace más fácil estudiar la implementación, por eso la seguridad no puede depender de obscurity. Revisiones públicas y tests pueden encontrar fallos antes.
¿Guard reemplaza MFA, passkeys o WAF?+
No. Guard es una capa anti-automation y abuse-protection. Acciones críticas aún requieren autenticación, autorización, CSRF, MFA/passkeys y controles de infraestructura.
¿El core necesita Internet?+
El flujo principal no requiere solicitudes salientes obligatorias. Updates, repository y attestation opcional son funciones separadas.
¿Un bot avanzado puede pasar el control interactivo?+
Sí. Browser controlado, AI o solver humano pueden imitar interacción. La autorización final sigue dependiendo de contexto servidor, limits, tokens y business policy.
Crea protección contra abuso que puedas auditar.
Runtime local. Autorización en servidor. Modelo de amenaza público. Sin CAPTCHA externo obligatorio.