What your IT department needs to know.

Architecture

Fdo. is a static web application. The server only serves HTML, CSS, JS and assets (fonts, icons, sitemap). There is no endpoint that receives data, no database, no authentication layer.

Frontend

Astro 4 (HTML/CSS generated at build time) + React 18 (only on the /es/app and /en/app routes).

PDF processing

pdf.js (rendering) and pdf-lib (writing). Both JavaScript, executed in the browser.

Packaging

JSZip to produce the download ZIP, also client-side.

Backend

None. Static server.

What goes over the network

When you open Fdo., the browser downloads:

• The site's HTML pages.
• The app's JavaScript bundles (only when entering /es/app or /en/app).
• The associated CSS.
• The Inter typeface (served from the same domain, not from Google Fonts).

When signing a PDF, no outbound HTTP request is made. You can verify this yourself: open the browser's DevTools, Network tab, filter by XHR/Fetch, load the app and sign a batch — you'll see zero new requests during processing.

Data that touches disk

Browser memory

Loaded PDFs live here while the tab is open. They are released when it closes.

localStorage

Only if you turn on "remember signature". Stores the signature image. Cleared from the app itself or by clearing site data.

sessionStorage / IndexedDB / cookies

None.

System disk

Only when you click download. The file goes to your standard downloads folder.

Server logs

Like any web server, the hosting provider records requests (IP, user-agent, path, HTTP status). Those logs are kept according to the provider's policy for as long as it takes to detect abuse. They are not joined with anything else, no user profiles are built, and they are not shared with third parties.

Subresource integrity and CSP

The static pages don't load external resources: every JS, CSS and font comes from the site's own domain. This reduces the surface to a single origin and removes the need for SRI on third parties (there are none).

A reasonable Content Security Policy for Fdo. is:

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: is needed for pdf.js workers and to build the signed files before download. 'unsafe-inline' on style-src is due to occasional inline styles generated by Astro; it can be removed by rewriting those styles as CSS modules if strictly required.

Dependencies and supply chain

The main dependencies (Astro, React, pdf-lib, pdf.js, JSZip, Inter) are public npm packages with active maintenance and thousands of weekly downloads. Fdo. pins specific versions in package-lock.json and builds happen from that lockfile.

If your organisation needs an SBOM or a vulnerability scan over the dependencies before approving usage, write to hola@fdo.app and the exact version plus a report will be provided.

Responsible disclosure

If you find a vulnerability — for example, a way to exfiltrate loaded PDFs or to inject scripts into the page — write to seguridad@fdo.app with reproducible details. Replies come within the same business day. There is no formal bounty programme, but the researcher is acknowledged publicly (with their permission).

To audit before approving usage

• Open /en/app in a clean tab with DevTools open.
• Check the Network tab: initial load only from fdo.app.
• Load a test PDF. Confirm zero outbound requests during processing.
• Inspect localStorage and sessionStorage: empty unless you enabled "remember signature".
• Close the tab, reopen /en/app: the remembered signature is still there; nothing else persists.