Security at Stowage.id

Per-organisation data isolation

Every load plan, item, RFQ, file and API key belongs to exactly one organisation. All access to private data goes through a single repository layer that requires the organisation identity; application code cannot write cross-organisation queries directly.

Automated tests in every release try to read and modify another organisation's data through every endpoint, and those attempts must fail. A release cannot proceed if a single one succeeds.

Authentication and access control

• Sign in with a one-time code by email or with Google. We do not store passwords.
• TOTP-based MFA is available to everyone and required for Business plans and up and for platform admins.
• Sessions use httpOnly, Secure, SameSite=Lax cookies, rotated at sign-in, with a CSRF token on every state-changing request.
• Per-organisation roles (owner, admin, planner, viewer, vendor agent) with per-action policies; permissions are checked on the server, not in the interface.
• API keys are only accepted in a header, stored as SHA-256 hashes and can be revoked at any time.
• Single sign-on (SSO) is available on Enterprise.

Encryption

• All traffic uses HTTPS (TLS 1.2 and up) with HSTS preload.
• Databases, file storage and backups are encrypted at rest by Cloudflare's infrastructure (AES-256).
• Private files can only be downloaded through HMAC-signed URLs valid for 15 minutes at most.

Application security

• A strict hash-based Content Security Policy plus X-Content-Type-Options, Referrer-Policy, Permissions-Policy and frame protection headers.
• Layered rate limiting at the edge and per user, IP and API key; Cloudflare Turnstile on sign-up, sign-in, RFQs and public forms.
• Uploads are size-limited, their type is verified from the file contents (magic bytes), they are stored under random names and never executed.
• Secrets are stored as Wrangler secrets, never in the repository. Dependencies are audited automatically in CI.
• Payments are processed by licensed providers; we never receive or store card data.

Operations, audit and backups

• Audit logs record sign-ins, permission changes, billing, data exports and every admin action. Organisation owners can review their organisation's log.
• Databases are protected by D1 Time Travel and encrypted daily exports to R2; restores are tested every month.
• Staff access to customer data is restricted, requires MFA and is recorded in the audit log.
• Incidents involving personal data are notified within 3 × 24 hours under the PDP Law — see the Privacy Policy.

Vulnerability disclosure

We value security researchers who help protect our users. Send reports to security@stowage.id with reproduction steps, the impact you expect and the URLs or endpoints involved.

Scope

stowage.id, api.stowage.id, embed.stowage.id, the application at stowage.id/app and the official embed widget.

Rules

• Only use accounts and organisations you own. Do not access, modify or keep other users' data; if you see some by accident, stop and report it.
• No denial-of-service, spam, social engineering of staff or users, or physical attacks.
• Do not use high-volume automated scanners that disrupt the Services.
• Give us reasonable time to fix the issue before disclosing it publicly — we aim to fix critical vulnerabilities within 30 days.

Our commitments

• Acknowledge your report within 3 business days and keep you updated on progress.
• Not pursue legal action against good-faith research that follows the rules above.
• Credit you as the finder (if you wish) once the fix is released. We do not currently run a paid bounty programme.

Out of scope

• Scanner output without demonstrated impact, missing headers without an exploit scenario, clickjacking on pages without sensitive actions.
• Vulnerabilities in third-party services (for example payment providers) — report them to the provider directly.
• Attacks that require an already compromised victim device.