Security

Sign-in

• Signing in uses a one-time link sent to your work email address. Fire Bid does not ask you to create or remember a password, so there is no password to reuse, guess, or leak.
• Only an email address your department administrator has already put on file can be used to sign in.
• Pages that show personnel information require a valid session; signed-out visitors are redirected to the sign-in page.

Who can reach what

• Access rules are enforced in the database, not just the interface. Hiding a button is not a security control, so Fire Bid also applies row-level access rules inside PostgreSQL. A request that asks for data the user should not have is refused at the data layer.
• Your own records stay yours. Regular accounts can read their own vacation selections, their own balance record, and their own eligibility calculations — not other people's. This is verified by direct testing against the database, not just by inspection.
• Administrator actions require an administrator. Every administrative operation re-checks the caller's role on the server before doing anything, so a request sent directly to the server by a non-administrator is rejected.
• Departments are separated. Department-owned records carry the department they belong to, and access rules restrict reads and writes to the requester's own department.

Audit history

Administrative changes — balance adjustments, overrides, bid open/close, standby promotions, manual vacation changes, role changes — are written to an audit record that captures who made the change, what changed, when, which department it affected, and the reason given.

That history is deliberately append-only: the application has no ability to edit or delete audit entries, and the database refuses deletion attempts even from an administrator account. This has been confirmed by direct testing.

Connections and hosting

• Traffic between your browser and Fire Bid is encrypted using HTTPS/TLS, and browsers are instructed to refuse unencrypted connections to the site.
• Fire Bid sends browser security headers that restrict where page content may be loaded from, prevent the site from being embedded in another site (clickjacking), and stop signed-in pages from being stored in shared caches.
• Privileged database credentials are used only by server-side code and are never sent to the browser.

Infrastructure providers

Fire Bid runs on managed infrastructure rather than self-managed servers. The certifications below belong to those providers and describe their platforms — they are not certifications of Fire Bid itself:

• Supabase provides Fire Bid's managed PostgreSQL database and sign-in infrastructure. Supabase reports SOC 2 Type 2 compliance and ISO 27001 certification for its platform.
• Vercel hosts the Fire Bid application and provides HTTPS/TLS termination and content delivery.

Fire Bid has not itself completed SOC 2, ISO 27001, HIPAA, CJIS, or FedRAMP programs, and does not claim to have done so. Using certified infrastructure is not the same as being certified, and this page will not blur that line.

Reporting a vulnerability

If you believe you have found a security problem in Fire Bid, please report it rather than testing it against a live department's data. A published security contact address is being finalised ahead of launch; in the meantime, report through your department administrator so it reaches us quickly. See also the Contact page.