Confianza y seguridad

Cómo protegemos sus datos

Última actualización: 5 de mayo de 2026

Nuestro compromiso

Apertur procesa fotos y metadatos que a menudo provienen de sus clientes. Nos tomamos esa responsabilidad muy en serio. Esta página describe los controles que tenemos implementados — alineados con el OWASP Top 10, el marco estándar de la industria en materia de riesgos de seguridad aplicativa.

Autenticación y control de acceso

Cada llamada a la API y cada acción del panel pasa por nuestra capa de autorización. Las sesiones están vinculadas a una huella del dispositivo y se rotan ante actividad sospechosa. Puede revocar cualquier sesión activa en cualquier momento desde la configuración de su cuenta.

Las claves API están delimitadas por proyecto y por entorno (producción vs zona de pruebas). Cada clave puede restringirse por rango de IP permitido, por dominio de origen permitido y, opcionalmente, por certificado TLS de cliente. Las claves de producción y de zona de pruebas no son intercambiables.

Las aplicaciones OAuth validan el origen de las solicitudes contra una lista blanca registrada con la aplicación — evitando el uso de tokens desde dominios no autorizados.

Cifrado

Las contraseñas se almacenan exclusivamente como hashes bcrypt con un factor de coste de 12 — nunca en texto claro, nunca cifradas de forma reversible. Las claves API se almacenan como hashes SHA-256 y solo se muestran una vez en el momento de su creación.

Todo el tráfico hacia apertur.ca y nuestra API se sirve sobre TLS, con HTTP Strict Transport Security (HSTS) aplicado en producción. Los webhooks salientes deben usar puntos de conexión HTTPS.

Los tokens criptográficos (identificadores de sesión, tokens de restablecimiento de contraseña, códigos de recuperación) se generan utilizando primitivas criptográficas de Node.js.

Validación de entrada y prevención de inyecciones

Todas las solicitudes entrantes se validan contra esquemas estrictos antes de llegar a la lógica de negocio. El acceso a la base de datos se realiza exclusivamente a través de un constructor de consultas con sentencias parametrizadas — no se concatena SQL en bruto con datos de usuario, eliminando toda una clase de vulnerabilidades de inyección SQL.

Las cargas de archivos se validan contra una lista blanca de tipos MIME, un tamaño máximo de archivo y límites de dimensiones de imagen.

Defensas del lado del navegador

Cada respuesta de página incluye una Content Security Policy que restringe los scripts, estilos y conexiones que el navegador ejecutará o abrirá. Los scripts en línea solo se ejecutan con un nonce criptográfico generado por petición; la inyección arbitraria de scripts queda bloqueada incluso si elude la codificación de salida (XSS, extensiones de navegador maliciosas, CDN comprometidos). El sitio de marketing, el panel y la página pública de carga tienen cada uno su propia política a medida — la página de carga es la más estricta, permitiendo solo scripts propios.

La misma respuesta también establece HSTS (seguridad de transporte), frame-ancestors (previene el secuestro de clics vía iframe), base-uri y form-action. Las violaciones de política se reportan a nuestro sistema de monitorización para revisión.

Autenticación multifactor

Soportamos varios segundos factores:

  • TOTP (Google Authenticator, 1Password, Authy, etc.)
  • Passkeys / WebAuthn (Touch ID, Face ID, Windows Hello, llaves de seguridad físicas)
  • Códigos de un solo uso por SMS
  • Códigos de recuperación (10 códigos de un solo uso, almacenados como hash)

Las contraseñas deben tener al menos 8 caracteres y se cotejan contra la base Have I Been Pwned — las contraseñas conocidas como comprometidas se rechazan en el registro y en el restablecimiento.

Limitación de tasa y prevención de abusos

Los endpoints de autenticación tienen límites de tasa estrictos por IP (5 intentos por minuto en inicio de sesión y registro; 3 por hora en restablecimiento de contraseña). La API en su conjunto está limitada para prevenir enumeración y denegación de servicio.

reCAPTCHA v3 puntúa los formularios públicos (registro, inicio de sesión, contacto). La detección de inicios de sesión sospechosos señala patrones anómalos de IP/dispositivo y dispara un correo de seguridad al propietario de la cuenta. Las señales de abuso multicuenta se evalúan en el momento del registro.

Manejo seguro de archivos

Cuando el servicio de carga recibe un archivo de un colaborador, este es validado, opcionalmente marcado con marca de agua o convertido en miniatura, y entregado directamente al destino configurado para el proyecto (S3, webhook, sistema de socio). Los originales no se conservan más allá del tiempo necesario para la entrega — generalmente minutos, con un límite máximo de 7 días.

Las sesiones de carga se vinculan a una URL de un solo uso. Las sesiones imponen expiración, número máximo de imágenes y listas blancas por tipo MIME. El cifrado de extremo a extremo puede activarse a petición para cargas de trabajo sensibles.

Registros de auditoría y supervisión

Los eventos relevantes para la seguridad se registran con marca de tiempo, dirección IP y agente de usuario: inicios de sesión exitosos y fallidos, alta y baja de MFA, creación y revocación de sesiones, restablecimientos de contraseña, cambios de claves API y cambios de destinos. Los propietarios de cuenta pueden consultar su propio registro de auditoría desde el panel.

Los registros de la aplicación están estructurados (JSON) y se conservan con fines de diagnóstico y respuesta a incidentes.

Los errores de aplicación no controlados son capturados por un sistema de seguimiento de errores separado. Antes de transmitir cualquier evento, los tokens de autorización, cookies e identificadores de sesión se eliminan de los encabezados, los cuerpos de petición de las rutas de autenticación y seguridad de cuenta se redactan, los parámetros de consulta sensibles (`token`, `code`, `secret`, `email`, `phone`) se eliminan, y el contexto de usuario se limita a un identificador de cuenta estable — nunca el correo electrónico, nombre o teléfono.

Infraestructura y configuración

Apertur está alojado en Canadá. Los encabezados de seguridad estándar (HSTS, atributos seguros de cookies, políticas cross-origin) se establecen en cada respuesta. Las respuestas de error se sanean — las trazas de pila y los detalles internos de error nunca se devuelven a los clientes. Las dependencias están fijadas mediante un archivo de bloqueo y se revisan antes de cada actualización.

Los logotipos e iconos proporcionados por socios son obtenidos, validados, procesados y almacenados en nuestra infraestructura en lugar de referenciarse en tiempo de ejecución. Esto elimina la dependencia de servidores controlados por terceros para el renderizado de la página de carga y evita que los operadores de alojamiento de imágenes observen el tráfico de sus usuarios finales.

Divulgación responsable

Acogemos los reportes de investigadores de seguridad. Si cree que ha descubierto una vulnerabilidad en Apertur, póngase en contacto con nosotros a través de nuestro formulario de contacto (asunto: Seguridad) antes de cualquier divulgación pública. Nos comprometemos a acusar recibo de los reportes en un plazo de 5 días hábiles y trabajaremos con usted en un calendario de divulgación coordinada. Actualmente no operamos un programa de recompensas por bugs remunerado, pero con gusto acreditamos a los investigadores en nuestras notas de versión.

Contacto

Para cuestionarios de seguridad, solicitudes de debida diligencia o para discutir un control específico con más detalle, utilice nuestro formulario de contacto y seleccione el tema Seguridad. Respondemos a las consultas de seguridad en un plazo de 2 días hábiles.

Confianza y seguridad | Apertur