Security
Security and operational safeguards.
Technical safeguards for the website, inquiries and the prepared application. This overview distinguishes reviewed implementation from evidence that must be established in production.
Editorial review
Editorial and source review: 12 October 2026 · Production acceptance pending
Evidence status
Each label describes the evidence available for that control.
Implemented
Present and inspectable in the local source or build. This does not confirm a deployed or independently audited environment.
Release check pending
The configuration or process needs evidence for the actual deployment. A development target is not an assured service.
Scope
Information website and separate website service; application and public data API have their own release gates. The open-beta date does not activate them automatically.
Website and inquiry handling
A static public site with a separate service for submitted forms.
Static pages
Implemented
HTML, fonts, images and scripts are served locally. Information pages require no application account. Forms send entered details to the website service when submitted.
Limited website storage
Implemented
No advertising pixels or external analytics SDKs. Session storage remembers the brand introduction per tab; the application has separate login cookies.
Content Security Policy
Implemented
The production build includes resource restrictions and hashes for approved scripts and styles. The proxy configuration adds framing protection. Actual response headers are checked after deployment.
Durable submission storage
Implemented
Submissions and their email jobs are stored in one database transaction. Repeated submissions are recognised. A stored request and a delivered email are separate states.
Encrypted email queue
Implemented
Pending email contents are encrypted with AES-256-GCM. This protects the mail queue, not every database field or backup. Key management forms part of operational acceptance.
Abuse controls and logging
Controls are scoped to each service.
Website forms
Implemented
Input validation, honeypots and rate limits; update subscriptions use double opt-in. IP-based website limits use in-memory counters and do not survive a process restart.
Website service logs
Implemented
Request logs contain route patterns and status codes. Form contents, URL tokens, email and IP addresses are excluded from these logs. Proxy and provider logs require a separate review.
Private operational access
Implemented
The website deployment template blocks public access to admin exports and operational endpoints. Permissions, network boundaries and database access are checked on the target server.
Public Passport API
Implemented
Demo issuance and signature verification have application-level limits. Release, proxy trust boundaries and behaviour under load are accepted separately from the website.
Application and Passport
Prepared capabilities, not a claim that public accounts have been released.
Authentication
Implemented
The application uses Auth.js email magic links and JWT sessions. Expiry, one-time use, cookie settings, abuse controls and session revocation require checks before public account access.
Passport integrity
Implemented
HMAC-SHA256 checks a signed calculation record using a server-side key. This is not independent public-key attestation and proves neither completed travel nor causally avoided emissions.
Shared journey data
Implemented
Titles, places and travel times can identify people. Passports are not automatically anonymous. Users need to review the information they share.
Erasure and export
Implemented
Account erasure and export features are prepared. Access checks, retained safety reports, sessions and backups form part of application acceptance; immediate erasure of every copy is not claimed.
Understand the data flows
Purpose, data categories and providers are reviewed together.
Application telemetry
Implemented
Events can include journey distances, timestamps, transport modes and countries. The absence of a user ID does not establish anonymity. Publishing aggregates needs a separate review.
External services
Implemented
Routing and weather queries can include places, coordinates and times. Map tiles may load directly in the browser. The provider inventory separates website services from configuration-dependent application services.
Production configuration
Evidence that must be established on the target system.
HTTPS and headers
Release check pending
Check certificates, redirects, HSTS, CSP and other response headers on farleda.eu. The application has its own CSP with additional provider allowances.
Database and backups
Release check pending
Demonstrate storage encryption, access protection, backup destination, retention and restoration. The encrypted mail queue does not replace these checks.
Email and contact paths
Release check pending
Accept Resend delivery, Hetzner mailboxes and receipt at support and security addresses using real test messages.
Operations and change evidence
Every check applies to a specific version.
Release checks
Implemented
Type checks, static builds, link and SEO audits, and targeted browser and website-service tests run locally. Scope and results are recorded per release; this is not an external audit.
Monitoring and response
Release check pending
Alerting, ownership and recovery procedures are established before publication. No 24/7 on-call coverage or contractual availability is currently promised.
Current assurance limits
We discuss procurement requirements before agreeing a pilot.
Certifications
No ISO 27001, SOC 2 or BSI C5 certification and no completed independent penetration test.
Enterprise identity
SAML SSO, OIDC federation and SCIM are not offered as available product capabilities. Requirements and effort are agreed before a pilot.
Verification
A valid Passport confirms a calculation record signed by Farleda. Source quality, actual travel and environmental impact need additional evidence.
Responsible disclosure
Report to security@farleda.eu. Until setup is confirmed, office@stoicera.com is the alternative contact. Start with a description without credentials or another person’s personal data.
In scope
- farleda.eu and its subdomains
- The Farleda app, including the authentication flow
- The public API endpoints under /api/public/v1 and the passport verification endpoint
- Anything that lets one account reach another account's data
Out of scope
- Services operated by third parties.
- Load tests, denial of service, social engineering and physical attacks.
The ground rules
- Use only your own test accounts and data.
- Stop immediately if another person’s data becomes accessible and report the finding privately.
- Describe reproduction steps, affected URL, time and potential impact.
- Coordinate remediation and disclosure. This page does not authorise disruptive testing.
Initial reply
Target: within three working days. This is not a guaranteed response time or an emergency channel.
Assessment and remediation
We discuss severity, additional information and an appropriate timeline with the reporter.
Acknowledgement
No paid bug-bounty programme. Public acknowledgement requires consent.
What we can send your review team
We discuss available drafts and release-specific evidence for your use case.
Contracts and data roles
Pilot scope, technical measures and any required DPA are agreed before the relevant processing starts.
Providers and data flows
The public inventory provides orientation. A contractual annex is scoped to the configuration actually in use.
Technical review
Test scope, known limitations and available results can be discussed in an agreed review. A complete SBOM or independent audit is not represented as already delivered.
Further reading: Trust · Providers and data flows · Release status · Changes.
