Seguridad

Seguridad que puedes comprobar.Sin humo.

Un registro de confianza vale lo que vale aquello que se niega a filtrar. Esta página explica, en llano, exactamente cómo protege TheHumanBehind los datos que hay detrás, y qué es lo que, a propósito, no guardamos jamás. Todo lo que lees aquí coincide con cómo está construido el sistema de verdad.

Tu email nunca es público
Ni nosotros podemos editar fecha o hash
Sin DNI y sin biometría
Infraestructura en la UE

La base de datos se defiende sola

La protección no es una promesa en el código de la aplicación: la impone la propia base de datos, al nivel más bajo, en cada consulta.

Seguridad a nivel de fila en todas las tablas

Todas las tablas del registro tienen seguridad a nivel de fila (RLS) activada. Un visitante anónimo solo puede leer fichas públicas: nunca borradores, nunca datos retirados, nunca tablas internas. Las reglas las aplica la base de datos en cada consulta, así que ni siquiera un error en la aplicación puede saltárselas.

Tu email no se expone jamás

Tu email vive únicamente en el sistema de autenticación. Ni siquiera es una columna de la tabla de fichas: no hay nada que pueda filtrarse a una ficha pública, al directorio ni a la API. Los mensajes de reclamación, que sí contienen un email, están cerrados solo a administradores.

Tu número y tu fecha, intocables también para nosotros

Una vez sellada una ficha, su número THB y su fecha de registro no pueden cambiarse desde ninguna cuenta que use la aplicación, incluidos nuestros propios administradores: un trigger de la base de datos rechaza el intento cada vez. La huella SHA-256 sigue siempre al contenido vigente, y cada versión anterior queda archivada para siempre en un registro de solo-añadir, así que una edición se ve en vez de pasar desapercibida. Lo que ese límite no puede descartar es que alguien con acceso privilegiado y directo a la infraestructura lo esquive, y no vamos a fingir lo contrario. Por eso el hash tiene una receta pública que cualquiera puede recalcular, y por eso, cada día, el registro entero se ancla en OpenTimestamps y en dos autoridades de sellado independientes: servicios que no controlamos, en infraestructura que no es nuestra. A partir de ahí la fecha deja de estar en nuestras manos, y puedes comprobarla sin preguntarnos.

Una sola superficie pública, una sola vista pública

La ficha pública, el directorio y la API leen de una única vista pública que contiene los campos públicos de una ficha y nada más. Los identificadores internos, los datos de la cuenta y las referencias de verificación quedan fuera estructuralmente: no se filtran, simplemente no están.

Intenta reescribir la historia

Esto no es un documento de políticas: es una restricción de la base de datos. Cualquier actualización que toque los campos sellados falla con el mismo error, la ejecute el titular o la ejecuten nuestros administradores:

psqlsql

update records set registered_at = now() where slug = 'laia';
-- ERROR:  immutable_columns

Todo lo que envías se revisa en la puerta

Las altas, las reclamaciones y el formulario de contacto pasan por la misma disciplina antes de que nada toque la base de datos o un buzón.

Validado en el servidor, siempre

Cada campo se vuelve a comprobar en el servidor con un esquema estricto: tipo, longitud y formato. Las validaciones del navegador están por comodidad, no por confianza. Si un valor no cumple las reglas, se rechaza antes de llegar a ningún sitio.

Consultas parametrizadas, siempre

La base de datos se consulta con parámetros enlazados, nunca pegando tu texto dentro de la consulta. Ese único hábito es lo que cierra la puerta a la inyección SQL: tu entrada se trata como dato, jamás como órdenes.

Tus palabras se escapan, no se ejecutan

Todo lo que envías y luego aparece en una página o dentro de un email se escapa primero. Un mensaje no puede colar un script (nada de cross-site scripting) ni añadir cabeceras a un email (nada de inyección de cabeceras). El texto se queda en texto.

Con límite de ritmo y filtro

Los endpoints de formularios tienen límite de ritmo y filtro antibots, para que nadie pueda machacarlos ni inundar un buzón. Las peticiones salientes solo llegan a dos servicios fijos y conocidos, así que un envío no puede convertirse en una petición a donde no debe.

Qué no guardamos jamás

El dato más seguro es el que nunca se recogió. La minimización es una regla de diseño del registro, no una preferencia.

Qué guarda el registro

Los campos públicos de tu ficha: nombre, tipo, dónde opera, persona responsable
Tu número THB, la fecha de registro sellada y la huella SHA-256
El email de tu cuenta: privado, solo para iniciar sesión y contactarte
En fichas verificadas, cuando se abra la verificación: el resultado de la comprobación de identidad, su fecha y una referencia de sesión

Qué no guardará nunca

Tu documento de identidad, ni copia, ni foto, ni escaneo
Datos biométricos de ningún tipo: ni plantillas faciales ni huellas de voz
Perfiles de rastreo o publicidad: la medición de audiencia es anónima y sin cookies
Contraseñas en formato legible: la autenticación la gestiona Supabase Auth

Las comprobaciones de identidad las realiza Stripe Identity, en la infraestructura de Stripe. TheHumanBehind nunca ve ni guarda tu documento: nuestra base de datos no tiene dónde ponerlo.

Los bordes también están vigilados

De la red al formulario de alta, la parte aburrida está cubierta.

Infraestructura en la UE

El sitio se sirve a través de Cloudflare (hosting, CDN y protección DDoS). La base de datos del registro corre en Supabase, sobre Postgres alojado en la Unión Europea (región eu-west).

Cookies que los scripts no pueden leer

Esta web no pone ninguna cookie de seguimiento. Las visitas se miden con Cloudflare Web Analytics, que no usa cookies ni crea un identificador de tu navegador. En la plataforma del registro, las cookies de sesión son HttpOnly, invisibles para JavaScript, y limitadas estrictamente al dominio de la plataforma.

Los bots chocan con tres muros

Las altas y las reclamaciones están protegidas por un campo honeypot, una comprobación de tiempo mínimo y Cloudflare Turnstile. Los tres se validan en el servidor, así que los trucos del lado del cliente no sirven.

La baja deja constancia, no un agujero

Las fichas no se borran nunca de forma definitiva. Si retiras la tuya, desaparece del directorio, pero el registro conserva la constancia mínima de que existió y fue retirada, para que un número no pueda ser reutilizado en silencio por otra persona.

Dónde viven los secretos

Hay un backend, y de eso se trata: el trabajo sensible corre en nuestros servidores, nunca en la página que te descargas. Esta es la línea que separa a los dos.

Tu navegador solo tiene claves públicas

La única clave de base de datos que llega a tu navegador es la publicable, y no puede hacer nada que la seguridad a nivel de fila no permita ya. La clave privilegiada que sí podría saltarse esas reglas nunca sale del servidor.

Los secretos se quedan en el servidor

Las claves de email, de comprobación de identidad y de verificación antibots viven solo en variables de entorno del lado del servidor. Mira el código fuente de la página y busca en el bundle: no están, porque nunca se envían al navegador.

Blindado en tránsito

Cada petición viaja por HTTPS, con HSTS para que el navegador se niegue a caer a HTTP en claro, y una content-security-policy estricta que limita lo que una página siquiera puede cargar o a dónde puede conectarse.

Mínimo privilegio, por defecto

Cada parte del sistema llega solo a lo que necesita: el sitio público lee una única vista de solo lectura, tu sesión toca únicamente tus propias filas, y un administrador ve solo la porción justa que una tarea requiere.

Una nota honesta

Ningún sistema es irrompible, y no vamos a fingir que este lo sea. Lo que sí podemos prometer es concreto: recogemos muy poco, no guardamos documentos sensibles que merezca la pena robar, cada entrada se valida y se escapa en el servidor, y la base de datos impone sus propias reglas incluso contra nosotros. El tráfico va por HTTPS y nuestros secretos nunca llegan a tu navegador. Si encuentras una vulnerabilidad, cuéntanoslo. Escríbenos con «Seguridad» en el asunto y responderemos lo antes posible.

Reportar un problema de seguridad