Skip to main content
Bibly
Find a race
Security overview

How we protect
your race data.

A plain-English summary of the security behind bibly.run — what we protect, how we protect it, and how we keep it that way over time.

Last full audit
May 2026
Clean — 0 findings
Audit cadence
Weekly + Monthly
Automated
Payments
Stripe
PCI-DSS Level 1
Hosting
Supabase
SOC 2 Type II
How we protect your data

Six layers, one promise.

Payments
Card and payment data is processed by Stripe, a PCI-DSS Level 1 certified provider. Bibly never stores raw card numbers — they are tokenised by Stripe before they ever reach our systems.
Database access
Every database query runs under row-level security: runners only see their own registrations, organisers only see their own events, and admin access is restricted and audited. Sensitive fields (bank details, payout information) are protected by stricter rules and never exposed to public or runner-level requests.
Encryption
All traffic to bibly.run is encrypted with TLS 1.2+, and our domain enforces HTTPS via HSTS. The full Bibly stack — front-end, API, database, and storage — is HTTPS-only.
Authentication
User logins are handled by Supabase Auth with bcrypt-hashed passwords, JWT-based session tokens, and per-role access scopes.
Browser hardening
Bibly sets a strict Content Security Policy that locks down where scripts, images, and connections can originate from. The policy is narrowed to our specific Supabase project — never a wildcard — so a compromise of an unrelated service can't reach our app.
Hosting
Bibly runs on Lovable (application hosting) and Supabase (database, auth, storage). Both providers carry SOC 2 Type II attestations. Cloudflare sits in front of the domain to mitigate DDoS and bot traffic.
Continuous auditing

How we stay clean over time.

Security gets quietly worse as code changes and new features ship. To prevent drift, Bibly is audited on an automated, recurring schedule:

CadenceWhat's checkedOutcome
WeeklyLive response headers, TLS, database access rules, recent code changes, secret scanQuiet pass, or alert to founder
MonthlyFull audit — every database table, all user roles tested for cross-account access, dependency vulnerabilities, repository reviewScored report with action items
QuarterlyThreat-model review, new attack-surface analysis, compliance posturePlan adjustments
Ad-hocTriggered by major changes (new payment method, new integration, vendor disclosure)Targeted deep dive

Each audit produces a versioned report. Findings are triaged by severity and tracked to closure.

Public reports

What we've published.

We publish a public summary of our security posture every quarter. Detailed findings remain internal, but the headline numbers and remediation status are open.

Next public report: August 2026.

Responsible disclosure

Found something? Tell us.

If you believe you've found a security issue affecting Bibly, we want to hear about it. Please email security@bibly.run with a description of the issue and steps to reproduce. We aim to acknowledge reports within 48 hours and resolve confirmed issues promptly. We do not pursue legal action against researchers acting in good faith within the scope described on this page.

Out of scope: denial-of-service, social engineering of staff, physical attacks, automated vulnerability scanners without a proof-of-concept, and any issue requiring a compromised end-user device.