Security

Access and account boundaries

TenderReader uses magic-link sign-in and signed HTTP-only session cookies. Production form posts use CSRF protection.

Pack, analysis, calendar, preference, and billing routes require the signed-in user and check the owning account before returning account data.

Data in transit and at rest

Production traffic is served over HTTPS by Railway, and the app sets HSTS in production.

The current production upload backend stores pack bytes in Postgres unless object storage is explicitly configured. Railway states customer project data is encrypted at rest; Cloudflare R2 states objects and metadata are encrypted at rest when that backend is enabled.

Model and training boundary

The production configuration currently uses the deterministic stub extraction engine unless a non-stub LLM provider is configured and reachable.

TenderReader code does not use uploaded customer packs to train a model. If a non-stub model provider is enabled, tender text is sent only for extraction under that provider's configured API path.

Monitoring and disclosure

The app emits structured request logs, health checks, scheduler sentinels, and optional Sentry events when SENTRY_DSN is configured. It does not claim SOC 2, ISO 27001, or enterprise compliance badges.

For now, report security issues through the operator contact channel already used for your TenderReader account or onboarding conversation. A public security mailbox should be configured before open marketing.

Please include reproduction steps, affected URLs, impact, and whether any account or tender-pack data may have been accessed.

Safe harbour posture

Good-faith reports that avoid privacy invasion, destructive testing, data exfiltration, spam, social engineering, and service disruption will be handled constructively.