▸ Security Posture · OWASP ASVS v4

Nuestra postura
de seguridad.

Esta es la auto-evaluación de AlgizSec contra el estándar OWASP ASVS (Application Security Verification Standard). Cada control apunta a evidencia técnica verificable en nuestro código. Sin maquillaje.

✓13
Verificado en código
⚙1
Vía proveedor certificado
○0
En roadmap
Matriz de controles ASVS · 14 áreas evaluadas
V1
Arquitectura y Modelado de Amenazas
Separación de datos por organización aplicada a nivel de base de datos.
Row Level Security (RLS) en todas las tablas de cliente: aunque dos empresas compartan infraestructura, jamás ven datos de la otra. La separación la hace Postgres, no el código.
📄 supabase/migrations/20260606_rls_all_tables.sql
✓
V2
Autenticación
JWT firmado, validado en cada endpoint sensible.
Supabase Auth con PKCE flow. Cada endpoint protegido valida el token con auth.getUser(token) antes de procesar. Tokens inválidos generan log de UNAUTHORIZED_ACCESS_ATTEMPT.
📄 api/sales/*.ts, api/whatsapp/*.js, api/email.js
✓
V3
Gestión de Sesiones
Rotación automática de tokens, sesión persistente segura.
autoRefreshToken: true + flowType: pkce. Refresh tokens se rotan automáticamente; el token expirado nunca llega al backend.
📄 src/supabase.ts:11
✓
V4
Control de Acceso
Roles a nivel de base de datos. Defensa en profundidad.
Rol admin codificado en app_metadata del JWT y validado por políticas RLS de Postgres. Aunque la aplicación falle, RLS rechaza el acceso.
📄 supabase/migrations/20260611_sales_pipeline.sql
✓
V5
Validación de Entradas
Sanitización en cada endpoint público. Detección de inyección.
Validación de tamaño de payload (16KB max en endpoints públicos), strip de caracteres de control, detector heurístico de prompt injection en el chatbot que responde con mensaje opaco sin gastar cuota de IA.
📄 api/sales/chat.ts
✓
V6
Cifrado de Datos en Reposo
Cifrado at-rest vía infraestructura cloud certificada.
Datos persistidos en Supabase (AES-256 server-side encryption por default) sobre AWS RDS. Buckets de archivos cifrados en reposo. Sin claves en el cliente.
📄 Supabase Postgres + Storage (AWS infrastructure)
⚙
V7
Manejo de Errores y Logging
Bitácora de auditoría de solo escritura. Trazabilidad forense.
Cada acción se firma con HMAC-SHA256 (id|user|ip|metadata|timestamp) al insertarse. Triggers de Postgres rechazan UPDATE, DELETE y TRUNCATE sobre audit_logs: comprobado intentando modificarla con permisos totales de base de datos. La clave de firma la custodia AlgizSec, así que la bitácora es inalterable para cualquier usuario de la plataforma; el anclaje ante un tercero independiente está en desarrollo.
📄 supabase/migrations/20260410_audit_integrity.sql
✓
V8
Protección de Datos Sensibles
Datos sensibles nunca llegan al cliente sin autorización.
Service role key solo en el backend. Anon key con permisos limitados por RLS. Errores internos del servidor se sanitizan antes de responder al cliente (sin filtrar stacks, mensajes de proveedor, ni internals).
📄 api/_lib/circuitBreaker.js + handlers
✓
V9
Comunicaciones (TLS)
TLS 1.3 obligatorio. HSTS preload. Headers OWASP estrictos.
Strict-Transport-Security con preload + max-age 1 año. Content-Security-Policy restrictivo (script-src self, frame-ancestors self). X-Frame-Options DENY. Referrer-Policy strict-origin.
📄 next.config.mjs + vercel.json
✓
V10
Código Malicioso (XSS, Inyección)
Sanitización doble + CSP estricto contra XSS.
DOMPurify en cliente sobre cualquier HTML del usuario, validación server-side, CSP restrictivo. SQL injection imposible: queries parametrizadas vía Supabase SDK (nunca strings concatenados).
📄 src/components/* + CSP en next.config.mjs
✓
V11
Lógica de Negocio (Rate Limiting)
Defensa contra abuso, picos de costo y proveedores caídos.
Rate limiting en Edge (Vercel Edge Runtime, 0ms latencia). Circuit breakers compartidos para Twilio/Resend: 5 fallas consecutivas abren el circuito 60s, rechazo local en <5ms para proteger OpEx. Idempotency keys evitan duplicados ante latencia satelital.
📄 middleware.ts + api/_lib/circuitBreaker.js
✓
V12
Manejo de Archivos
Upload directo a bucket cifrado. URLs firmadas con expiración.
Archivos suben directo del navegador a Supabase Storage (no pasan por servidor de aplicación). Bucket protegido con RLS por user_id. Visualización vía signed URL con expiración de 1 hora.
📄 src/hooks/useVaultFiles.ts + src/components/PDFViewer.tsx
✓
V13
Seguridad de API
Cada endpoint: rate limit + JWT + validación de payload.
Patrón uniforme: 1) rate limit por IP, 2) validación de Bearer token, 3) gate de tamaño del payload, 4) operación, 5) respuesta sin detalles internos.
📄 api/sales/chat.ts, api/health.ts
✓
V14
Configuración Segura
Secretos fuera del cliente. Headers de seguridad por defecto.
API keys solo en variables de entorno del backend. Cliente recibe solo VITE_SUPABASE_ANON_KEY (cuyos permisos están limitados por RLS). Pre-commit hook bloquea cualquier .env, .pem o clave SSH en el repositorio.
📄 .githooks/pre-commit + .vercelignore
✓

Lo que esta página es — y lo que no

  • Es una declaración honesta y verificable de cómo está implementada hoy nuestra seguridad. Cada fila apunta a un archivo del repositorio que un auditor puede revisar.
  • No es una certificación de tercero (ISO 27001, SOC 2). Esas son auditorías formales en el roadmap; las publicaremos aquí cuando estén firmadas.
  • No es garantía absoluta. Ninguna lo es. Es nuestra mejor implementación al día de hoy, abierta a escrutinio.
▸ Responsible Disclosure

¿Encontró algo? Cuéntenos primero.

Si descubre una vulnerabilidad en AlgizSec, repórtela de forma privada a security@algizsec.com. Respondemos en menos de 72 horas y reconocemos públicamente a quienes reportan en buena fe. No tomamos acciones legales contra investigación responsable de seguridad.

PGP / consulta de coordinación disponible bajo solicitud.
AlgizSec · Última revisión: 2026-09-29 · ← Volver al inicio