How Nata Photo is secured, the results of a full security audit, and how to report a vulnerability.

Version 2.0.1 · Last updated 2026-07-14 · Status: Living document

Guiding principles. This document and the codebase follow six code principles — Clean Code, YAGNI, DRY, KISS, Semantic naming/HTML, and A11y (accessibility). The security posture favors the smallest attack surface and least privilege (KISS/YAGNI), one canonical header definition mirrored across deployment targets (DRY), and clear, auditable controls (Clean Code). Full definitions: PRINCIPLES.md.

• Nata Photo has no backend. Every file is opened, decoded, and sorted locally in the browser via the File System Access API. Nothing is uploaded; there is no telemetry and no network egress (enforced by connect-src 'self').
• Dependency tree is clean. After this audit pnpm audit reports "No known vulnerabilities found" for both the full tree and the production (--prod) tree. The production container ships only express, helmet, compression (0 known vulns) plus the static build.
• Deployment is hardened and nginx-free. A single container runs a tiny Express + helmet static server as a non-root user with a read-only root filesystem, all Linux capabilities dropped, and no-new-privileges.
• World-class HTTP headers, including a strict Content-Security-Policy, cross-origin isolation (COOP + COEP + CORP), HSTS, and a deny-by-default Permissions-Policy.

Please report security issues privately — do not open a public GitHub issue.

• Preferred: open a private advisory at https://github.com/frama21/nata-photo/security/advisories/new.
• A machine-readable contact is published per RFC 9116 at /.well-known/security.txt.

We aim to acknowledge reports within a few days. Because the app is fully client-side and self-hostable, most fixes ship as a new build/image that operators pull.

Nata Photo is a local-first, zero-backend single-page app. Its security model follows from that:

The remaining attack surface is the classic client-side one: malicious media files or a malicious nata-photo-db.json trying to crash/DoS the tab or pollute app state, cross-site attacks against the served page (XSS, clickjacking, framing), and supply-chain risk in dependencies. Each is addressed below.

flowchart LR
  subgraph Untrusted
    IMG[Image / video / RAW bytes]
    DB[nata-photo-db.json]
    NET[The wider web]
  end
  subgraph Browser["Browser origin (sandboxed, cross-origin isolated)"]
    APP[Nata Photo SPA]
  end
  subgraph Local["Local filesystem (user-granted handle)"]
    FS[(Chosen folder)]
  end
  IMG -->|header-only parse, bounded decode| APP
  DB -->|validated + sanitized| APP
  APP -->|explicit copy/move only| FS
  NET -. blocked by CSP connect-src 'self' .-> APP

Set by server/index.js via helmet, and verified on live responses:

default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none';
form-action 'self'; img-src 'self' blob: data:; media-src 'self' blob:;
font-src 'self' data:; style-src 'self' 'unsafe-inline';
script-src 'self' 'wasm-unsafe-eval'; worker-src 'self' blob:;
connect-src 'self' blob: data:; manifest-src 'self'; upgrade-insecure-requests

All responses carry the full header set (verified live):

Permissions-Policy explicitly denies accelerometer, autoplay, browsing-topics, camera, display-capture, encrypted-media, geolocation, gyroscope, interest-cohort, magnetometer, microphone, midi, payment, publickey-credentials-get, screen-wake-lock, serial, sync-xhr, usb, and xr-spatial-tracking.

COOP: same-origin + COEP: require-corp place the document in a cross-origin isolated context: the tab is process-isolated, cross-origin data cannot leak into it, and SharedArrayBuffer / high-resolution timers are available to the WASM decoders. CORP: same-origin on every response satisfies COEP for our (entirely same-origin) subresources.

Production vs. development: the only reason any advisory ever appeared in the tree is the shadcn CLI, which is a build-time-only dev dependency. It is never installed into the production image and never reaches a browser. The pnpm.overrides in package.json keep even the dev tree green.

pnpm install
pnpm audit             # full tree  → No known vulnerabilities found
pnpm audit --prod      # prod only  → No known vulnerabilities found

The app deploys as one container via docker compose — no nginx, no reverse proxy required (see Dockerfile, docker-compose.yml, server/index.js).

Image (Dockerfile)

• Multi-stage: (1) build the SPA with pnpm on node:22-slim; (2) npm ci --omit=dev the three runtime deps on node:22-alpine from a committed lockfile; (3) a minimal node:22-alpine runtime that contains only server/index.js, the audited node_modules, and the static dist.
• Runs as the unprivileged built-in node user (no root).
• No shell tooling, no build toolchain, no frontend dependencies in the final image.
• HEALTHCHECK uses Node's built-in fetch against /healthz (no curl/wget).

Runtime (docker-compose.yml)

The server (server/index.js) sets all headers from §4, accepts only GET/HEAD (405 otherwise), serves hashed /assets/* immutably and HTML/sw.js/manifest with no-cache, emits correct application/wasm / application/manifest+json MIME types, returns real 404s for missing assets (never HTML-as-JS), and shuts down gracefully on SIGTERM/SIGINT.

HSTS is only honoured over HTTPS. For a public deployment, terminate TLS at your platform edge (Cloudflare, a cloud load balancer, or an existing Caddy/Traefik) and forward to the container; set TRUST_PROXY=1 so protocol detection and HSTS reflect the external scheme.

• pnpm audit and pnpm audit --prod → clean.
• pnpm build (typecheck + bundle) → passes.
• pnpm lint → clean.
• Live header check on /, /assets/*, /manifest.webmanifest, /.well-known/security.txt → CSP + all headers present; WASM served as application/wasm; immutable vs no-cache correct.
• POST / → 405; missing /assets/x.js → 404; unknown route → SPA shell.
• SIGTERM → graceful shutdown.

Quick header check:

docker compose up -d --build
curl -sSD - http://localhost:8080/ -o /dev/null

• style-src 'unsafe-inline' — required by Tailwind v4 / Radix's runtime-injected styles. The residual risk (CSS injection) is low given React output-escaping and the absence of any HTML-injection sink; a nonce-based style policy is impractical with this component stack.
• HSTS requires HTTPS — the container speaks HTTP; the header is inert unless TLS is terminated in front of it (see §6).
• MediaInfoModule.wasm is not emitted at build time — Vite cannot statically resolve mediainfo's runtime new URL(...), so video metadata degrades gracefully (the extractor catches the failure and returns default metadata). This is a functional note, not a security issue: nothing is fetched cross-origin, and CSP would block it if it were.
• Browser support — the app requires the File System Access API (Chromium-based browsers only).

• Pin the image by digest and run pnpm audit / docker scout (or Trivy) in CI on every build.
• Serve only over HTTPS; consider submitting the domain to the HSTS preload list.
• Keep the container updated (docker compose pull && up -d --build) so dependency patches ship.
• Do not add cross-origin <script>/connect sources to the CSP; the app is designed to need none.
• If you fork, keep shadcn in devDependencies and retain the pnpm.overrides.

• 2026-07-14 — Full audit for v2.0.1: patched exifreader; removed shadcn from production deps; pinned dev-tree advisories to a clean pnpm audit; added DB sanitization and folder-name validation; replaced the nginx deployment with a hardened non-root Node/helmet single-container setup; added security.txt and this policy.