Lo que tu departamento de IT necesita saber.

Arquitectura

Fdo. es una aplicación web estática. El servidor sirve únicamente HTML, CSS, JS y assets (fuentes, iconos, sitemap). No hay endpoint que reciba datos, no hay base de datos, no hay capa de autenticación.

Frontend

Astro 4 (HTML/CSS estático generado en build) + React 18 (sólo en las rutas /es/app y /en/app).

Procesamiento PDF

pdf.js (visualización) y pdf-lib (escritura). Ambas en JavaScript, ejecutadas en el navegador.

Empaquetado

JSZip para generar el archivo ZIP de descarga, también en cliente.

Backend

Ninguno. Servidor estático.

Qué viaja por la red

Cuando abres Fdo., el navegador descarga:

• Las páginas HTML del sitio.
• Los bundles de JavaScript de la app (sólo al entrar en /es/app o /en/app).
• Los CSS asociados.
• La fuente Inter (servida desde el mismo dominio, no desde Google Fonts).

Al firmar un PDF no se hace ninguna petición HTTP de salida. Lo puedes verificar tú mismo: abre las DevTools del navegador, pestaña Network, filtra por XHR/Fetch, carga la app y firma un lote — verás cero peticiones nuevas durante el procesamiento.

Datos que tocan disco

Memoria del navegador

Los PDFs cargados viven aquí mientras la pestaña está abierta. Se liberan al cerrarla.

localStorage

Sólo si activas «recordar firma». Guarda la imagen de la firma. Se borra desde la propia app o limpiando los datos del sitio.

sessionStorage / IndexedDB / cookies

Ninguno.

Disco del sistema

Sólo cuando pulsas descargar. El archivo va a tu carpeta de descargas estándar.

Logs del servidor

Como cualquier servidor web, el proveedor de hosting registra peticiones (IP, user-agent, ruta, código HTTP). Esos logs se conservan según la política del proveedor durante el tiempo necesario para detectar abusos. No se cruzan con nada más, no se generan perfiles de usuario y no se comparten con terceros.

Política de Subresource Integrity y CSP

Las páginas estáticas no cargan recursos externos: todo el JS, CSS y fuentes vienen del propio dominio. Esto reduce la superficie a un único origen y elimina la necesidad de SRI para terceros (no hay terceros).

Una Content Security Policy razonable para Fdo. es:

default-src 'self';
img-src 'self' data: blob:;
style-src 'self' 'unsafe-inline';
script-src 'self';
font-src 'self';
connect-src 'self' blob:;
worker-src 'self' blob:;
object-src 'none';
base-uri 'self';
form-action 'none';
frame-ancestors 'none';

blob: es necesario para los workers de pdf.js y para crear los archivos firmados antes de la descarga. 'unsafe-inline' en style-src se debe a estilos inline puntuales generados por Astro; se puede eliminar reescribiendo esos estilos en CSS modules si fuera obligatorio.

Dependencias y suministros

Las dependencias principales (Astro, React, pdf-lib, pdf.js, JSZip, Inter) son paquetes públicos de npm con mantenimiento activo y miles de descargas semanales. Fdo. fija versiones concretas en package-lock.json y el build se hace desde ese lockfile.

Si tu organización requiere un análisis SBOM o un escaneo de vulnerabilidades sobre las dependencias antes de aprobar el uso, escribe a hola@fdo.app y se facilita la versión exacta y un informe.

Divulgación responsable

Si encuentras una vulnerabilidad —por ejemplo, una forma de exfiltrar PDFs cargados o una inyección de scripts en la página— escribe a seguridad@fdo.app con los detalles reproducibles. Se contesta en el mismo día laborable. No hay programa de recompensas formal, pero se reconoce públicamente al investigador (con su permiso).

Para auditar antes de aprobar el uso

• Abrir /es/app en una pestaña limpia con DevTools abiertas.
• Verificar la pestaña Network: carga inicial sólo desde fdo.app.
• Cargar un PDF de prueba. Confirmar cero peticiones de salida durante el procesamiento.
• Inspeccionar localStorage y sessionStorage: vacíos salvo si activas «recordar firma».
• Cerrar la pestaña, reabrir /es/app: la firma marcada como recordada sigue ahí; ningún otro dato persiste.