ByteHeavy
ByteHeavy
ByteHeavy
Seguridad y confianza
La mayoría de las agencias dicen 'seguridad de nivel bancario' y se quedan ahí. Preferimos mostrarte los detalles concretos — incluidas las partes que todavía están en desarrollo — porque una promesa vaga vale menos que una que se puede verificar.
Nuestro sistema de tickets funciona sobre PostgreSQL con Seguridad a Nivel de Fila (Row-Level Security) habilitada y forzada, conectado mediante un rol de aplicación dedicado que deliberadamente no es superusuario. Eso significa que las reglas de control de acceso viven dentro de la propia base de datos, no solo en el código de la aplicación. Lo probamos directamente: una sesión limitada al correo de un cliente realmente no puede leer los tickets de otro cliente, incluso en la misma conexión y el mismo rol de base de datos. Si un futuro error en nuestro código de aplicación intentara consultar los datos equivocados, la base de datos lo rechaza antes de que la consulta llegue a ejecutarse — el aislamiento no depende de que recordemos escribir la cláusula WHERE correcta cada vez.
Cada respuesta incluye una Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options y una Permissions-Policy restrictiva — las defensas estándar contra el clickjacking, los ataques de MIME-sniffing y buena parte del XSS. Las compilaciones de producción se publican sin source maps, así que la estructura exacta de nuestro código fuente no queda expuesta a quien abra las herramientas de desarrollador.
Cada endpoint de tickets y formulario de contacto tiene limitación de tasa por IP, e incluye un campo honeypot invisible para usuarios reales pero que los bots suelen rellenar automáticamente — los envíos que lo activan reciben una respuesta de éxito falsa en lugar de un rechazo, de modo que el abuso automatizado ni siquiera se entera de que fue bloqueado. Toda la entrada de los formularios se valida en el servidor con un esquema estricto antes de que llegue a la base de datos, sin importar lo que el frontend permita pasar.
No vamos a afirmar que una funcionalidad existe antes de que exista. La autenticación de dos factores (TOTP con código QR) y un servicio dedicado de autenticación/sesión basado en Rust están diseñados y planificados, pero aún no funcionan en producción — por ahora, la búsqueda de tickets se hace por coincidencia de correo electrónico, que es un mecanismo de conveniencia, no un inicio de sesión con nivel de contraseña. Los archivos adjuntos en los tickets aún no son compatibles intencionalmente, específicamente porque todavía no hemos construido la capa de escaneo de malware que querríamos tener delante de ellos. Preferimos entregar una función tarde antes que entregarla insegura.
Si no puedes verificar una afirmación de seguridad, es marketing. Preferimos que puedas.