Seguridad

De un vistazo

• La misma protección en todos los planes

  Todos los planes tienen el mismo cifrado y el mismo aislamiento. Los planes superiores suman control, no seguridad.

• Cifrado en reposo

  Los volúmenes de PostgreSQL, los objetos de R2 y las copias de seguridad están cifrados en reposo por los proveedores. Los datos enviados, el HTML, los PDF y las versiones en Markdown de los informes además se cifran con una clave de datos por espacio de trabajo antes de escribirse en el almacenamiento de objetos; borrar un espacio de trabajo destruye la clave.

• Cifrado en tránsito

  TLS 1.2 o superior en cada endpoint público; HSTS; el tráfico interno entre la aplicación y el plano de render queda en la red privada de Railway y se autentica con un HMAC.

• Alojamiento en la UE

  La aplicación, la base de datos, los procesos en segundo plano y el plano de render funcionan en la región EU West de Railway (Ámsterdam); los datos enviados, el HTML, los PDF y las versiones en Markdown se guardan en Cloudflare R2 con la restricción de jurisdicción de la UE. La región es una propiedad de tu espacio de trabajo; hoy solo está activa la región de la UE.

• Seguridad a nivel de fila

  Cada tabla de clientes lleva un id de espacio de trabajo y PostgreSQL aplica seguridad a nivel de fila sobre ella. El servicio web se conecta con un rol que no puede saltársela, y todo el conjunto de pruebas se ejecuta una segunda vez con ese rol.

• Versiones de plantilla inmutables

  Publicar crea una versión de solo agregado fijada a un hash del contenido del kit; triggers de la base de datos rechazan cambios en versiones publicadas. Los informes se vinculan a una versión, y el HTML y el PDF quedan fijos al generarse, con sus hashes guardados en el informe.

• No se ejecuta código de clientes

  Una plantilla es JSON validado contra un esquema. El plano de render la interpreta con un kit fijo de widgets; Chromium funciona con JavaScript desactivado y todas las solicitudes de red bloqueadas. El plano de render no tiene base de datos, ni bucket, ni secretos aparte de la clave HMAC.

• Un DPA para cada cliente

  La descripción del tratamiento, las medidas técnicas y organizativas y la lista de subencargados son anexos. Nos comprometemos a notificarte una violación de datos personales dentro de las 48 horas de enterarnos.

• Enlaces firmados e informes privados en Pro

  Las URL firmadas dan acceso por tiempo limitado sin un enlace compartible; los informes privados solo se abren para miembros del espacio de trabajo con sesión iniciada. El modo sin retención, en Pro, borra cada informe un tiempo fijado después de que está listo.

• Cada PDF se puede comprobar

  Desde Standard, la huella de cada PDF real se registra al generarse. Cualquiera puede comprobar una copia en la página de verificación: el archivo se procesa en su navegador y nunca se sube. Los registros no guardan contenido del informe y se conservan 10 años.

• Todavía sin BAA de HIPAA

  No envíes a Pressfox información de salud protegida bajo la ley de EE. UU. Los datos de salud según el RGPD (art. 9) se pueden tratar bajo el DPA cuando tu propia base legal los cubre.

1. La arquitectura en un párrafo

Tres componentes desplegables. Un plano de control en Django se encarga de cuentas, espacios de trabajo, plantillas, informes, facturación y la API pública. Un plano de render privado en Node recibe un documento validado, los datos y un tema, genera el HTML, lo imprime a PDF con Chromium y devuelve ambos; no guarda nada ni se conecta a nada. Una app estática en React es el panel y el editor. Cada tabla de clientes lleva un id de espacio de trabajo y la seguridad a nivel de fila de PostgreSQL respalda el aislamiento propio de la aplicación, así un error en una consulta no puede filtrar filas de otro espacio de trabajo.

2. Infraestructura y proveedores

La aplicación, la base de datos PostgreSQL, los procesos en segundo plano y el plano de render funcionan en Railway, en su región EU West (Ámsterdam). Cloudflare provee DNS, TLS, la CDN, los nombres de host propios para informes en tu dominio y el almacenamiento de objetos R2 con la restricción de jurisdicción de la UE. Paddle gestiona los pagos como comerciante registrado. Resend envía los correos desde su región de envío en la UE (Irlanda). Sentry recibe los reportes de errores en su región de la UE (Fráncfort), sin el contenido de los datos enviados. Anthropic procesa texto para las funciones de IA opcionales. Google se usa solo si eliges iniciar sesión con Google. Producción funciona separada de staging.

La página de subencargados (en inglés) es la lista única y oficial: qué hace cada proveedor, dónde, con qué mecanismo de transferencia y el aviso que damos antes de agregar uno.

3. Cifrado y claves

• Los datos enviados, el HTML, los PDF y las versiones en Markdown de los informes se cifran con una clave de datos por espacio de trabajo antes de escribirse en el almacenamiento de objetos. Borrar un espacio de trabajo destruye su clave.
• TLS 1.2 o superior en cada endpoint público, con HSTS. La aplicación y el plano de render se comunican por la red privada de Railway, y cada solicitud entre ellos se autentica con un HMAC.
• Las claves de API son por espacio de trabajo, con prefijo pf_live_ o pf_test_, se muestran una vez, se guardan como hash y se pueden revocar en cualquier momento. Las claves de prueba generan informes con marca de agua que no se miden.
• Las contraseñas de los informes se guardan como hash, nunca en texto plano.
• Las contraseñas de los PDF se usan una vez, para cifrar el archivo, y se borran con los datos enviados cuando el informe está listo; no podemos recuperarlas. La contraseña de permisos es aleatoria para cada informe y se descarta, así que nadie puede cambiar después los permisos de un PDF.
• Solo identificadores públicos: las claves internas nunca salen de la base de datos. Los enlaces de informes usan un token aleatorio aparte que no se deriva del id del informe.

4. Aislamiento de espacios de trabajo y roles

• Cada tabla de clientes lleva un id de espacio de trabajo y PostgreSQL aplica seguridad a nivel de fila sobre ella, así la base de datos misma rechaza filas de otro espacio de trabajo.
• El servicio web se conecta a la base de datos con un rol que no puede saltarse la seguridad a nivel de fila.
• En la integración continua, todo el conjunto de pruebas se ejecuta una segunda vez con ese rol, así una consulta que solo funciona esquivando las políticas hace fallar el build.
• Cuatro roles (owner, admin, editor, viewer) se corresponden con una sola matriz de permisos; cada endpoint de la API se revisa con el mismo mecanismo.

5. Inicio de sesión y sesiones

• Sin contraseñas. Inicias sesión con un código de un solo uso enviado por correo, o con Google. Tres intentos fallidos gastan el código y pides uno nuevo.
• Un registro nuevo queda pendiente hasta que se confirma su código, así nadie puede crear una cuenta con una dirección que no controla.
• Los inicios de sesión y los pedidos de código tienen límite de frecuencia.
• Las sesiones viven en el servidor. Una sesión termina después de 7 días sin uso y después de 30 días como máximo.
• Tu cuenta lista tus sesiones activas, para que puedas cerrar sesión en otros dispositivos.
• Te avisamos por correo cuando tu cuenta inicia sesión desde un dispositivo nuevo.

6. El plano de render

No se ejecuta código de clientes. Una plantilla es JSON validado contra un esquema, interpretado por el plano de render con un kit fijo de widgets. Chromium la imprime con JavaScript desactivado y todas las solicitudes de red bloqueadas. Cada render tiene plazos, así un trabajo trabado se detiene en lugar de quedar corriendo. El plano de render solo es accesible en la red privada: no tiene dirección pública, ni base de datos, ni bucket, ni secretos aparte de la clave HMAC.

7. Los datos que envías

• Cada envío de datos se valida contra el contrato de la plantilla antes de generar nada; los datos que no coinciden se rechazan.
• Aquello con lo que se hizo el informe, los datos enviados y las imágenes descargadas de tus URL, se borra en cuanto el informe está listo, o 24 horas después de un render fallido.
• Las imágenes se descargan de tus URL detrás de una protección contra falsificación de solicitudes del lado del servidor (SSRF): se revisa la dirección y la conexión queda fijada a la dirección revisada.
• Los metadatos de las fotos, incluida la ubicación GPS, se quitan de las versiones de impresión de tus imágenes.
• La versión en Markdown de un informe la genera código a partir del informe mismo, no la IA.
• Las propiedades de un PDF llevan solo su título, el nombre del emisor e identificadores públicos: nunca otros datos que enviaste, ni los nombres o versiones de las herramientas que lo generaron.

8. Acceso a los informes

Por informe, al crearlo: enlace abierto (token imposible de adivinar), contraseña, fecha de vencimiento y, en Pro, URL firmadas e informes privados. Desde Standard, el propio PDF también puede abrirse solo con una contraseña: AES-256, definida por informe o tomada de un campo de los datos; el lector puede seguir imprimiendo, copiando y usando un lector de pantalla. La puerta de contraseña se bloquea después de intentos fallidos repetidos. Los códigos QR se firman por informe. Las páginas de informes alojados no crean cookies de rastreo; la única cookie es la de la puerta de contraseña, limitada al nombre de host del informe. La personalización por espacio de trabajo de las páginas de error, vencimiento y contraseña todavía no está terminada; hoy llevan el nombre de Pressfox.

9. Verificar un documento

• Desde Standard, el PDF de cada informe real recibe un registro de verificación cuando está listo: su huella SHA-256, el nombre del emisor y la hora de emisión, y después si una corrección lo reemplazó o el emisor lo revocó. Los informes de prueba y los de modo sin retención no reciben ninguno.
• Quien tenga el PDF puede comprobarlo en la página de verificación, en app.pressfox.io/verify o en /verify de tu propia dirección de informes. El navegador calcula la huella; el archivo nunca se sube. La respuesta es auténtico (quién lo emitió y cuándo), reemplazado, revocado con el motivo del emisor, o no encontrado.
• Cuando tu espacio de trabajo tiene su propia dirección de informes, cada PDF imprime una línea que dice dónde comprobarlo: en esa dirección, nunca en la nuestra. Ahí, la página responde solo por los documentos de tu espacio de trabajo.
• No encontrado significa que Pressfox no emitió el archivo o que cambió después de emitirse: anotar o volver a guardar un PDF cambia su huella. Una copia firmada con tu proveedor de firma es un archivo nuevo; comprueba la copia que emitió Pressfox.
• Un registro no guarda título, datos ni etiquetas, así que sobrevive al informe: se conserva 10 años y se borra con el espacio de trabajo. Las comprobaciones tienen límites en el borde de la red y por dirección, sin captcha ni cookies. La verificación prueba que un archivo no cambió desde que se emitió; no es una firma ni un sello electrónico.

10. Webhooks y la API

• Cada envío de webhook se firma siguiendo la especificación Standard Webhooks, así tu endpoint puede comprobar que vino de nosotros y no fue alterado; la marca de tiempo firmada te permite rechazar envíos viejos.
• Los envíos fallidos se reintentan en una escala de 1 minuto a 24 horas. Un endpoint que falla 3 días sin un solo éxito se desactiva automáticamente; la app muestra cuándo y por qué junto a él, y el registro de auditoría lo anota. Una vez corregido el receptor, un propietario o administrador reactiva el endpoint con un clic, conservando su URL y su secreto de firma. Eso reinicia el conteo de fallas, empieza 3 días nuevos y queda en el registro de auditoría; los eventos perdidos mientras estuvo desactivado se pueden reenviar desde sus envíos.
• Los endpoints de webhook pasan la misma protección contra SSRF que la descarga de imágenes, fijada a la dirección revisada, así un webhook no puede apuntar a direcciones internas.
• La API acepta claves de idempotencia, así una solicitud reintentada después de un timeout no crea un segundo informe.
• La API tiene límites de solicitudes por clave de API y por espacio de trabajo, en ventanas de un minuto: 600 solicitudes por minuto por clave, de las cuales 120 pueden crear informes, y 1,200 solicitudes (240 creaciones de informes) por minuto entre todas las claves de un espacio de trabajo, de prueba y reales juntas. Una solicitud que pasa un límite se rechaza con HTTP 429 y un encabezado Retry-After; cada respuesta contada lleva RateLimit-Limit, RateLimit-Remaining y RateLimit-Reset. Ver rate_limited (en inglés).
• El inicio de sesión, el asistente de IA, el Playground, las importaciones de plantillas y la puerta de contraseña de los informes alojados también tienen límites de frecuencia.

11. Funciones de IA y agentes de IA

Las funciones de IA de Pressfox son opcionales y trabajan solo con texto, nunca con imágenes: borradores de traducción de una plantilla, traducción de los campos de texto del informe que marcas, resúmenes en los informes, el asistente del editor y la creación de un borrador de plantilla a partir de un PDF que subes (solo su texto; el PDF se borra en menos de 24 horas). Un informe generado nunca llama a un modelo: las traducciones de plantilla se revisan y se fijan al publicar, y el texto de IA que entra en un informe se escribe una vez, antes de imprimir, y se borra con los demás insumos del informe cuando está listo. Solo se envían los campos marcados de un informe; el texto se pasa como datos, nunca como instrucciones, y se revisa antes de usarlo (los marcadores, el formato y los números tienen que sobrevivir). Este texto lo procesa Anthropic en Estados Unidos, bajo su DPA y las Cláusulas Contractuales Tipo, y no se usa para entrenar modelos; los informes, los datos enviados y los PDF se quedan en la UE. Las funciones de IA están desactivadas en los espacios de salud.

Los agentes de IA pueden conectarse a Pressfox por MCP. Apruebas cada uno en una pantalla de consentimiento OAuth; un agente conectado puede encontrar plantillas y crear, leer y compartir informes (no puede borrar informes, cambiar plantillas ni tocar miembros, claves o facturación), y puedes desconectarlo en cualquier momento. MCP está en vista previa: lo activamos para un espacio de trabajo a pedido.

12. Acceso del personal

No hay panel de administración en producción; las operaciones se hacen desde la consola autenticada del proveedor de alojamiento y con comandos de gestión auditados. Hoy solo el fundador tiene acceso a producción.

13. Pagos

Paddle es nuestro comerciante registrado: se encarga del checkout, la facturación, los impuestos y los reembolsos. Los datos de tarjeta van a Paddle; nunca recibimos números de tarjeta.

14. Registros, monitoreo y auditoría

• Los registros llevan ids de solicitud, nunca contenido de los datos enviados. Una prueba automática de borrado de registros en el build lo demuestra.
• Los errores van a Sentry en la UE (Fráncfort), sin el contenido de los datos enviados.
• Un registro de auditoría de solo agregado anota inicios de sesión, cambios de rol, creación y revocación de claves de API, publicaciones y borrados de plantillas. Se guarda 1 año en todos los planes y 2 años en Pro y Enterprise, donde propietarios y administradores también pueden descargarlo en CSV o NDJSON.

15. Copias de seguridad y recuperación

La base de datos tiene recuperación a un punto en el tiempo: podemos restaurarla a cualquier minuto de las últimas 4 semanas. Las copias de seguridad están cifradas en reposo. Ensayaremos una restauración cada trimestre, la primera antes del lanzamiento general. El objetivo es volver en menos de 4 horas y perder como máximo 15 minutos de cambios; publicaremos los tiempos medidos cuando un ensayo los registre. Los borrados y las revocaciones (espacios de trabajo, informes, archivos, claves de API, enlaces de informes, envíos, invitaciones y miembros) se registran fuera de la base de datos, y nuestro procedimiento de restauración vuelve a aplicar los registrados desde el punto de restauración antes de reabrir el servicio.

16. Retención y borrado

En los planes de pago, los informes alojados, sus PDF y sus enlaces se guardan mientras la suscripción esté activa y durante 30 días después de que termine, y después se borran. En Free se guardan durante 7 días; en Enterprise, según el contrato. Un propietario puede fijar un plazo más corto para el espacio de trabajo, y una integración para un informe. Cada informe conserva el plazo con que se creó: cambiar entre planes de pago nunca lo acorta. El almacenamiento de informes tiene un límite por plan; al llegar a él, los informes nuevos se rechazan y nunca se borra nada para hacer lugar. Los informes de prueba se guardan 24 horas en todos los planes. Aquello con lo que se hizo un informe se va antes: sus datos enviados y las imágenes descargadas de tus URL se borran en cuanto está listo, y 24 horas después de un render fallido. El borrado de un informe o de un espacio de trabajo llega a la base de datos, al almacenamiento de objetos, a la caché de la CDN y a los archivos temporales del plano de render. Un espacio de trabajo borrado se puede restaurar durante 30 días; después borramos sus datos y destruimos su clave de cifrado. Las copias de seguridad de la base de datos pueden conservar esa clave como máximo 35 días más; el sistema está diseñado para que, cuando caduquen, los datos ya no se puedan descifrar, ni por nosotros ni por nadie. La exportación del espacio de trabajo produce un archivo legible por máquina con plantillas, versiones, perfiles de marca, informes y metadatos.

17. Modo sin retención

En Pro y Enterprise, un propietario puede activar el modo sin retención para el espacio de trabajo, y una integración puede pedirlo para un informe. Un informe hecho así se borra un tiempo fijado después de que está listo: entre 5 minutos y 24 horas, 1 hora si no eliges otra cosa.

Los datos que envías se borran en cuanto el informe está listo, y de inmediato si la generación falla. Las páginas y el PDF se guardan en un almacenamiento aparte que borra todo en un plazo de dos días, aunque falle nuestro propio proceso de borrado.

Recoge el informe dentro de ese plazo: por webhook y luego una descarga con tu clave de API, o con un enlace firmado. Después, la API responde que el plazo terminó. Borrar el informe por la API termina el plazo antes.

Las funciones que guardan datos o los envían a otro lado están desactivadas en este modo: los enlaces abiertos (los informes usan enlaces firmados), compartir por correo, la traducción y los resúmenes con IA, y los formularios a medio completar. El título del informe sale de tu solicitud, o del nombre de la plantilla y la fecha, nunca de los datos.

Si el espacio de trabajo pasa a un plan sin este modo, sigue activo hasta que un propietario lo apaga. Limita lo que guardamos; no cambia nuestro papel: mientras generamos un informe seguimos tratando sus datos, como tu encargado bajo el DPA.

18. Respuesta a incidentes

Cuando algo sale mal, seguimos cinco pasos:

1. Contener el problema y conservar la evidencia.
2. Determinar el alcance: qué espacios de trabajo, qué datos, desde cuándo.
3. Rotar las claves y los secretos que puedan estar afectados.
4. Notificar a los clientes afectados dentro de las 48 horas de enterarnos de una violación de datos personales, como compromete el DPA (en inglés), y a las autoridades cuando la ley lo exige.
5. Corregir la causa y documentarla.

19. Tu parte

La seguridad es compartida. De tu lado:

• Guarda las claves de API en un almacén de secretos, nunca en el código ni en el navegador, y usa claves de prueba en desarrollo.
• Elige la política de acceso adecuada para cada informe: una contraseña, un vencimiento o URL firmadas para todo lo sensible.
• Fija versiones de plantilla en producción, para que una publicación nunca cambie un informe que envían tus sistemas.
• Verifica la firma de cada webhook antes de confiar en él.
• Quita a los miembros que dejan tu equipo y rota cualquier clave de API que hayan podido ver.
• No envíes información de salud protegida de EE. UU.: no firmamos acuerdos de socio comercial de HIPAA.

20. Divulgación responsable

Si encuentras una vulnerabilidad, avísanos. Escribe a hello@pressfox.io con el asunto "Reporte de seguridad", con detalle suficiente para que podamos reproducirla. Confirmamos la recepción dentro de 2 días hábiles. No hay recompensa en dinero; si quieres, te agradecemos por nombre en esta página.

Dentro del alcance: pressfox.io, app.pressfox.io, api.pressfox.io, reports.pressfox.io, *.pressfox.app, la API y el servidor MCP.

Fuera del alcance: Paddle, Cloudflare y Google en sí (repórtalo a ellos); denegación de servicio; spam; ingeniería social; ataques físicos; y los datos de otros clientes.

Reglas: prueba solo en tu propio espacio de trabajo. Si llegas a datos que pertenecen a otra persona, detente, no los guardes y repórtanoslo.

Puerto seguro: no perseguimos ni denunciamos a quienes investigan de buena fe bajo estas reglas. Nuestros datos de contacto también están publicados en /.well-known/security.txt (RFC 9116).

21. Certificaciones

Ninguna todavía. Pressfox no tiene informe SOC 2, ni certificado ISO 27001, ni acuerdo de socio comercial de HIPAA. Nuestros proveedores tienen sus propias certificaciones; son de ellos, no nuestras, y no las reclamamos.

22. Lo que todavía no, dicho claramente

• Todavía no hay segundo factor para iniciar sesión.
• No hay CAPTCHA en los formularios públicos; hoy el abuso se controla con límites de frecuencia y registros pendientes.
• Todavía no hay encabezado Content-Security-Policy.
• Todavía no se completó una prueba de penetración externa; hay una planeada antes del lanzamiento general y publicaremos el resumen.
• Todavía no hay página pública de estado.
• No hay informe SOC 2 ni certificado ISO 27001.
• Todavía no hay almacenamiento dedicado, ni claves de cifrado gestionadas por el cliente, ni almacenamiento en tu propio bucket. Son opciones de Enterprise que conversamos a pedido.
• No hay otra región que la UE. Otras regiones llegarán cuando un cliente lo necesite, con almacenamiento por región.
• No hay acuerdo de socio comercial de HIPAA ni región dedicada a salud.
• Todavía no hay inicio de sesión único (SAML); solo código por correo y Google.
• Ubicado en la UE, no soberano de la UE: nuestros proveedores de alojamiento son empresas de EE. UU. con planos de control globales, obligadas por Cláusulas Contractuales Tipo.

23. Historial de versiones