Skip to main content
fjordFIRE
Join the waitlist

Reference

Security.

Last updated · June 2026

This page describes the security architecture of the in-product fjordFIRE application, the authenticated product currently in private beta. The marketing site you are reading is a separate static surface and does not store user data. The two are deployed independently.

It is the technical companion to the trust page: same posture, with the actual mechanisms (algorithms, providers, processes) named. Meant to be skimmed first and audited second.

Authentication

  • Passwordless by design. Sign in with a one-time magic code sent to your email, or with Google OAuth. There are no user passwords on the system, so there's nothing to phish, breach, or reuse.
  • Multi-factor available to every household member. Any user in a household can enable TOTP (RFC 6238) via an authenticator app, with printed recovery codes for account recovery. It isn't an admin-only option. SMS-based codes are not offered: SIM-swap is a real attack vector.
  • Sessions use secure HTTP-only cookies with SameSite=Lax (the policy that supports OAuth sign-in callbacks). State-changing routes apply CSRF protection at the API boundary. Session tokens are rotated on auth events.

Encryption

  • At rest: the database and backups are encrypted by the hosting provider. Sensitive secrets, like TOTP keys and equivalent material, receive additional application-layer encryption with AES-256-GCM.
  • In transit: HSTS with 2-year preload, served by the app on every request. TLS termination is handled by Railway's managed edge.
  • Content security: a strict Content-Security-Policy is served on every page of the app; inline scripts use per-request nonces.

Browser hardening

The app sets a defence-in-depth set of HTTP response headers on every request:

  • X-Frame-Options: DENY. The app cannot be embedded in an iframe by another origin. Blocks clickjacking.
  • X-Content-Type-Options: nosniff. The browser will not second-guess a declared content type. Blocks MIME-confusion attacks.
  • X-XSS-Protection: 1; mode=block. Legacy header that still helps older browsers refuse to render pages flagged as containing reflected XSS.
  • Referrer-Policy: strict-origin-when-cross-origin. Full URLs go to same-origin requests only; cross-origin requests get the origin alone. Limits what third parties learn from a click.
  • Permissions-Policy. Camera, microphone, and geolocation are disabled outright. interest-cohort=() opts out of FLoC and any successor cohort-tracking signal.

Audit log

Every write to your data is recorded in an audit log: timestamp, user, before/after values, request context. Each entry is cryptographically hash-chained to the previous entry, so any tampering anywhere in the history is detectable. You can verify chain integrity from inside the product, and export the complete log as CSV or JSON.

Audit-log rows are retained for the lifetime of the household. Older entries have PII anonymised on a rolling schedule (180 days), while the chain itself is preserved so integrity remains verifiable.

Hosting

  • Region: EU only (Railway, EU region). Application servers, databases, and backups are all in the EU.
  • Network: all traffic is terminated at a managed edge with DDoS protection.
  • Backups: point-in-time recovery for the database. Backups are encrypted; retention is configured at the infrastructure level by the hosting plan.
  • Tenancy: fjordFIRE is a multi-tenant application; data isolation is enforced at the application layer, with row-level security at the database as a second line of defense. All data access is scoped to the relevant user or household context.

Sub-processors

We use the smallest viable set of vendors. Each one has a specific role and a documented data-processing agreement.

  • Railway: application + database hosting (EU region).
  • Umami: privacy-friendly analytics, no personal identifiers.
  • exchangerate-api.com: daily FX rates inside the app (currency code → USD).
  • Frankfurter: ECB-anchored daily FX rates for the public calculators on this website.
  • World Bank Open Data API: per-country inflation (10-year geometric-mean CPI) and PPP price-level data, cached on our side.
  • Mistral: European LLM provider for the in-app AI companion. Conversations are not used for model training; retention is 30 days.
  • Google OAuth: optional sign-in provider, only invoked for users who choose to sign in with Google.
  • Resend: transactional email (sign-in codes, notifications).
  • Stripe: payment processing for paid plans. Enabled at public launch; not active during private beta.
  • Cloudflare Turnstile: bot protection on the public waitlist form.

The list above is the source of truth. Sub-processor changes are reflected on this page and in the privacy notice.

What we do not have

  • No bank-credential vault. There is no integration that asks for them.
  • No third-party advertising or tracking SDKs (no Google Analytics, no Facebook pixel).
  • No session-replay or screen-recording.
  • No machine-learning training on user data.

Information security management

  • Internal financial-correctness audit: the math layer is reviewed line by line against the formulas, FX paths, inflation handling, edge cases, and consistency rules it should obey. The first audit covered twelve categories of correctness; findings are tracked and patched in the changelog.
  • Defense-in-depth: row-level security at the database, parameterised queries throughout, strict input validation at the application boundary, principle-of-least-privilege on every internal interface.
  • Code review: every release is reviewed against the OWASP top-ten plus an internal checklist before deploy. The reviewer is not the author.

Operations

  • Access control: production access is restricted, requires multi-factor authentication, and is logged.
  • Patching: dependencies are tracked and updated on a regular schedule; security advisories trigger out-of-band patches.
  • Incident response: if a security incident affects your data, we will notify you without undue delay and within the timelines required by GDPR.

Reporting a vulnerability

Found something? Email [email protected]. We commit to acknowledging within 72 hours, keeping you informed during triage, and not pursuing legal action against good-faith research that follows responsible disclosure.

This page is updated whenever the underlying mechanisms change. Material product changes are recorded in the changelog.