How company data is kept apart

Every table carries row level security policies, so the boundary between two companies is enforced by Postgres rather than by application code remembering to filter. A query that forgot its company filter returns nothing rather than another company data.

• Each policy resolves your company from your signed-in identity, not from anything the browser sends.
• Read and write are granted separately, per table, per operation.
• Documents are authorised through the tender they belong to, so a document cannot be reached without access to its parent tender.
• The public, unauthenticated role has no read access to any application table.

Authentication is handled by Supabase Auth. Company-email signups are confirmed by email; Google signups use the verified identity returned by Google.

• Company-email workspaces are keyed on the email domain.
• Personal Google accounts on consumer domains receive unique workspace identifiers; the shared provider domain is not claimed.
• Consumer and disposable email providers remain blocked for password-based signup.
• Session tokens are held in cookies and refreshed server side on each request.

For company-email accounts, the company domain comes from the verified email address. For personal Google accounts, the workspace identifier is derived from the authenticated user ID. Neither value is read from a client-submitted field.

Account creation runs as a single database operation that either creates the workspace and its representative together or does neither. A second company-email signup on an existing company domain is rejected rather than quietly joining that company.

Application data lives in managed Postgres and object storage operated by Supabase. Traffic is served over TLS, and data at rest is encrypted by the hosting provider. Uploaded tender documents are stored against the company that owns them and are subject to the same access rules.

Being straightforward about the gaps is more useful to you than a page of badges. As things stand:

• There is no third-party security certification. We do not hold SOC 2, ISO 27001 or equivalent, and we will not claim otherwise on a questionnaire.
• No external penetration test has been carried out yet.
• There is no paid bug bounty. Reports are still welcome and will be acknowledged.
• The product is early. Controls described above are implemented; anything not described above should be assumed not to be in place.

If your procurement process needs something on this list, say so when you get in touch and we will tell you honestly where it stands rather than when it might arrive.

Send reports to security@quicktenders.co.ke with enough detail to reproduce the issue. We aim to acknowledge within three working days.

What we ask of reporters:

• Give us a reasonable window to fix the issue before publishing it.
• Use only accounts and data you own for testing.
• No automated scanning, load testing or denial of service against the production service.
• Do not access, modify or retain another company data. If you reach it accidentally, stop and tell us what you saw.

Other contact routes are on the contact page.