Security
Last Updated: June 24, 2026
1. Our Security Commitment
At Pathways2Bids, the security of your data and the integrity of the platform are a top priority. We apply industry-standard practices across our infrastructure, codebase, and operations to protect your information against unauthorized access, loss, or misuse.
This page describes our current security practices. We continuously review and improve these controls as the platform evolves.
2. Data Transmission
All communication between your browser and the Pathways2Bids platform is encrypted using Transport Layer Security (TLS 1.2 or higher). This means data you send to and receive from our servers — including login credentials, form inputs, and session data — is encrypted in transit.
Our platform enforces HTTPS across all pages. Requests made over unencrypted HTTP are automatically redirected to HTTPS.
3. Authentication & Access Controls
We use Supabase Authentication to manage user accounts and sessions. Our authentication system includes the following protections:
- Passwords are hashed using bcrypt before storage. We never store plain-text passwords.
- Email verification is required before a new account can be used to sign in.
- Support for Google OAuth sign-in, which delegates authentication to Google's secure identity infrastructure.
- Rate limiting on authentication endpoints to mitigate brute-force and credential stuffing attacks.
- Secure, short-lived session tokens with automatic refresh.
- Role-based access controls (RBAC) restrict platform features to authorised users only.
4. Infrastructure & Hosting
Pathways2Bids is hosted on a combination of trusted cloud infrastructure providers:
- Vercel — Our application frontend and API routes run on Vercel's global edge network. Vercel is SOC 2 Type II certified and operates with strict security controls across its infrastructure.
- Supabase — Our database, authentication, and backend services are hosted on Supabase, which runs on AWS infrastructure with encryption at rest (AES-256) and in transit (TLS). Supabase is SOC 2 Type II certified.
5. Data Storage & Encryption
All data stored in our database is encrypted at rest using AES-256 encryption, managed by our infrastructure provider (Supabase/AWS).
Sensitive fields such as passwords are additionally hashed before storage and are never stored or transmitted in plain text.
Database access is restricted by Row Level Security (RLS) policies that ensure each user can only read and modify data they are authorised to access.
6. Application Security
We apply secure development practices throughout our codebase:
- Input validation and parameterised queries to protect against SQL injection.
- Content Security Policy (CSP) and other HTTP security headers to mitigate cross-site scripting (XSS) and clickjacking.
- CSRF protection on state-changing operations.
- Dependencies are regularly reviewed and updated to address known vulnerabilities.
- Server-side actions and API routes are authenticated before processing sensitive operations.
7. Access Controls & Internal Practices
Access to production systems is restricted to authorised personnel only.
Administrative access to the database and infrastructure is protected by multi-factor authentication (MFA).
We follow the principle of least privilege — team members and service accounts are granted only the minimum permissions necessary to perform their function.
8. Incident Response
In the event of a security incident or data breach, we will:
- Investigate promptly to understand the scope and impact.
- Take immediate steps to contain the incident and protect affected users.
- Notify affected users as required by applicable law, including within 72 hours where mandated.
- Conduct a post-incident review and implement improvements to prevent recurrence.
9. Vulnerability Disclosure
We welcome responsible disclosure of security vulnerabilities. If you believe you have identified a security issue in our platform, please contact us at the address below with:
- A description of the vulnerability and how it can be reproduced.
- The potential impact of the vulnerability.
- Any relevant screenshots, logs, or proof-of-concept details.
Please do not publicly disclose the vulnerability until we have had reasonable time to investigate and respond (typically 30 days). We will acknowledge your report within 5 business days.
10. Contact
If you have security questions, concerns, or wish to report a vulnerability, contact us at: