Security & Trust
Start with the operating explanation, then open the technical review for concrete controls, implementation references, current gaps and disclosure contacts.
Venue records are separated by organization identifiers, database policies, role checks and scoped API credentials. The primary database, authentication and storage data plane is configured for EU residency. Optional video, AI and consent-gated analytics services can involve documented cross-border processing, so the DPA and sub-processor list—not a broad slogan—describe the complete chain.
The production payment rail uses Stripe-hosted components and Stripe Connect, so Booking Bible stores provider identifiers rather than primary account numbers. Charges and refunds retain the payment intent’s account context to avoid crossing venue accounts. Other provider-aware code paths are not live venue offerings.
Billing or payment questions? billing@bookingbible.com
Venue roles separate administration, management, reception, instruction and client access. Sensitive server actions apply explicit permission checks, and important admin mutations write audit records. TOTP-based MFA is available; privileged enforcement is being staged and is not described as universally mandatory until the production rollout is complete.
Need help with team access? support@bookingbible.com
The application combines security headers and a nonce-based content policy with auth rate limits, signed webhook verification, input validation, audit logs and error-data scrubbing. The latest internal verification date is May 13, 2026. Independent assurance is still a due-diligence item, so this page separates implemented controls from pending certification or third-party testing.
Technical or integration questions? integration@bookingbible.com
The platform DPA is public and its acceptance is versioned. Data-subject workflows support access, correction, export, objection and deletion, with identity verification and legal-retention exceptions where required. Venues remain controllers for their own client processing and must configure lawful bases, notices and retention choices appropriately.
The public sub-processor register explains the services involved and their processing purpose. Consent grants and withdrawals are recorded with evidence fields, while marketing and analytics flows consult the relevant consent and suppression gates. Contractual notice and objection mechanics are governed by the DPA.
GDPR or DPA questions? dpo@bookingbible.com
Organization identifiers, Postgres Row Level Security and context-specific authorization guards form the tenant boundary. Private storage uses short-lived signed URLs through a TTL-clamping helper. Application-level encryption is applied to designated sensitive fields; it is not advertised as universal field encryption.
-- representative tenant policy
CREATE POLICY "tenant_select"
ON public.bookings FOR SELECT
USING (organization_id = user_org_id());Source: src/lib/auth/*-context.ts, src/lib/storage/signed-urls.ts, supabase/migrations
Public routes use schema validation, scoped API keys or bearer identity, venue scoping and layered rate limits. Configurable outbound URLs pass through SSRF controls. Webhook consumers verify provider signatures at their ingress, while outbound partner events use HMAC signatures and stable delivery identifiers.
curl "https://bookingbible.com/api/v1/calendar?start=2026-08-01&end=2026-08-07" \
-H "X-API-Key: bb_live_…" \
-H "X-Organization-ID: org_…"Source: src/lib/api/registry.ts, src/lib/security/ssrf-guard.ts, src/lib/webhooks
Billing or payment integration? billing@bookingbible.com
Supabase Auth provides the session boundary. New passwords pass the platform strength policy, auth flows have distributed rate-limit strategies with a local fallback, and TOTP MFA is available. Privileged MFA hard enforcement remains a reviewed rollout decision, so the public posture does not claim it is mandatory for every account.
const result = validatePasswordStrength(candidate);
if (!result.valid) {
return { ok: false, feedback: result.feedback };
}Source: src/lib/auth/password-policy.ts, src/lib/auth/rate-limit-strategies.ts, src/lib/auth/mfa-guard.ts
Venue roles map to explicit permissions rather than relying on UI visibility. Server mutations resolve an authenticated context and required permission before changing scoped data. Administrative actions use the canonical audit helper, which adds request context and redacts common secret and personal-data patterns before persistence.
await requirePermission('settings.membership');
await auditLog({
action: 'membership.settings_updated',
organizationId,
changes,
});Source: src/lib/auth/permission-registry.ts, src/lib/admin/helpers.ts, src/lib/audit/redact-for-audit.ts
Authentication questions? support@bookingbible.com
Middleware generates a per-request nonce and is the single document-CSP authority. Production policy blocks nonce-less inline scripts, restricts framing and narrows third-party script, frame and connection origins. Embeds receive a separately reviewed framing contract.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: script-src 'nonce-…' 'strict-dynamic' …Source: next.config.ts (SECURITY_BASE_HEADERS), src/lib/security/csp-builder.ts, src/middleware.ts
Inbound provider webhooks verify signatures before business logic and record verification evidence. Outbound partner events are signed. Structured logs, request identifiers, audit records and Sentry capture provide correlation, with scrubbers reducing the chance that credentials or common personal-data patterns reach telemetry.
const verified = await verifyWebhookSignature(request, provider);
if (!verified.ok) {
return Response.json({ error: 'invalid_signature' }, { status: 401 });
}Source: src/lib/webhooks/webhook-verify-helpers.ts, src/lib/observability, src/lib/audit
Database, storage and external-system recovery have documented runbooks, reconciliation steps and restore-drill evidence. Feature flags and kill switches reduce rollout blast radius. Recovery objectives remain conditional on verified provider configuration such as PITR; the platform does not publish an unverified RPO as a guarantee.
release change
→ staged rollout
→ monitor errors and payment funnel
→ kill switch or rollback when abort criteria fireSource: docs/DISASTER_RECOVERY.md, docs/BACKUP_RULES.md, docs/ROLLOUT_RULES.md
Technical or integration questions? integration@bookingbible.com
Data-subject workflows cover access, correction, export, objection and deletion across core profile and venue records. Deletion retains records where a documented legal exception applies. Marketing and analytics paths consult consent and suppression gates, and retention jobs apply the configured policy.
const consent = await hasActiveConsent(userId, 'marketing_email');
if (!consent) {
return { skipped: true, reason: 'no_consent' };
}Source: src/lib/legal, src/lib/marketing, docs/COMPLIANCE_RULES.md
DPA acceptance is versioned, the sub-processor register is public, and material processing changes follow the contract’s notice mechanics. Incident records support assessment and communication; the GDPR 72-hour rule is applied when the legal notification threshold is met rather than treated as a blanket promise for every alert.
processing change
→ update registry and assessment
→ apply contractual notice
→ retain acknowledgement evidenceSource: /dpa, /legal/sub-processors, docs/INCIDENT_RESPONSE.md
Security issues go to security@bookingbible.com. The machine-readable policy at /.well-known/security.txt contains the current contact, encryption and expiry details. Booking Bible coordinates disclosure timing with the reporter and affected parties.
curl https://bookingbible.com/.well-known/security.txtSource: /.well-known/security.txt, docs/security/PENTEST_SCOPE.md
GDPR or DPA questions? dpo@bookingbible.com
Still have questions? support@bookingbible.com
Found something? Email security@bookingbible.com. Current disclosure and encryption details are published at /.well-known/security.txt. We coordinate disclosure timing with the reporter and affected parties.
Acknowledgments. Published credits are added with the reporter's consent when a validated report results in a fix.
Security & Trust
Start with the operating explanation, then open the technical review for concrete controls, implementation references, current gaps and disclosure contacts.
Venue records are separated by organization identifiers, database policies, role checks and scoped API credentials. The primary database, authentication and storage data plane is configured for EU residency. Optional video, AI and consent-gated analytics services can involve documented cross-border processing, so the DPA and sub-processor list—not a broad slogan—describe the complete chain.
The production payment rail uses Stripe-hosted components and Stripe Connect, so Booking Bible stores provider identifiers rather than primary account numbers. Charges and refunds retain the payment intent’s account context to avoid crossing venue accounts. Other provider-aware code paths are not live venue offerings.
Billing or payment questions? billing@bookingbible.com
Venue roles separate administration, management, reception, instruction and client access. Sensitive server actions apply explicit permission checks, and important admin mutations write audit records. TOTP-based MFA is available; privileged enforcement is being staged and is not described as universally mandatory until the production rollout is complete.
Need help with team access? support@bookingbible.com
The application combines security headers and a nonce-based content policy with auth rate limits, signed webhook verification, input validation, audit logs and error-data scrubbing. The latest internal verification date is May 13, 2026. Independent assurance is still a due-diligence item, so this page separates implemented controls from pending certification or third-party testing.
Technical or integration questions? integration@bookingbible.com
The platform DPA is public and its acceptance is versioned. Data-subject workflows support access, correction, export, objection and deletion, with identity verification and legal-retention exceptions where required. Venues remain controllers for their own client processing and must configure lawful bases, notices and retention choices appropriately.
The public sub-processor register explains the services involved and their processing purpose. Consent grants and withdrawals are recorded with evidence fields, while marketing and analytics flows consult the relevant consent and suppression gates. Contractual notice and objection mechanics are governed by the DPA.
GDPR or DPA questions? dpo@bookingbible.com
Organization identifiers, Postgres Row Level Security and context-specific authorization guards form the tenant boundary. Private storage uses short-lived signed URLs through a TTL-clamping helper. Application-level encryption is applied to designated sensitive fields; it is not advertised as universal field encryption.
-- representative tenant policy
CREATE POLICY "tenant_select"
ON public.bookings FOR SELECT
USING (organization_id = user_org_id());Source: src/lib/auth/*-context.ts, src/lib/storage/signed-urls.ts, supabase/migrations
Public routes use schema validation, scoped API keys or bearer identity, venue scoping and layered rate limits. Configurable outbound URLs pass through SSRF controls. Webhook consumers verify provider signatures at their ingress, while outbound partner events use HMAC signatures and stable delivery identifiers.
curl "https://bookingbible.com/api/v1/calendar?start=2026-08-01&end=2026-08-07" \
-H "X-API-Key: bb_live_…" \
-H "X-Organization-ID: org_…"Source: src/lib/api/registry.ts, src/lib/security/ssrf-guard.ts, src/lib/webhooks
Billing or payment integration? billing@bookingbible.com
Supabase Auth provides the session boundary. New passwords pass the platform strength policy, auth flows have distributed rate-limit strategies with a local fallback, and TOTP MFA is available. Privileged MFA hard enforcement remains a reviewed rollout decision, so the public posture does not claim it is mandatory for every account.
const result = validatePasswordStrength(candidate);
if (!result.valid) {
return { ok: false, feedback: result.feedback };
}Source: src/lib/auth/password-policy.ts, src/lib/auth/rate-limit-strategies.ts, src/lib/auth/mfa-guard.ts
Venue roles map to explicit permissions rather than relying on UI visibility. Server mutations resolve an authenticated context and required permission before changing scoped data. Administrative actions use the canonical audit helper, which adds request context and redacts common secret and personal-data patterns before persistence.
await requirePermission('settings.membership');
await auditLog({
action: 'membership.settings_updated',
organizationId,
changes,
});Source: src/lib/auth/permission-registry.ts, src/lib/admin/helpers.ts, src/lib/audit/redact-for-audit.ts
Authentication questions? support@bookingbible.com
Middleware generates a per-request nonce and is the single document-CSP authority. Production policy blocks nonce-less inline scripts, restricts framing and narrows third-party script, frame and connection origins. Embeds receive a separately reviewed framing contract.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: script-src 'nonce-…' 'strict-dynamic' …Source: next.config.ts (SECURITY_BASE_HEADERS), src/lib/security/csp-builder.ts, src/middleware.ts
Inbound provider webhooks verify signatures before business logic and record verification evidence. Outbound partner events are signed. Structured logs, request identifiers, audit records and Sentry capture provide correlation, with scrubbers reducing the chance that credentials or common personal-data patterns reach telemetry.
const verified = await verifyWebhookSignature(request, provider);
if (!verified.ok) {
return Response.json({ error: 'invalid_signature' }, { status: 401 });
}Source: src/lib/webhooks/webhook-verify-helpers.ts, src/lib/observability, src/lib/audit
Database, storage and external-system recovery have documented runbooks, reconciliation steps and restore-drill evidence. Feature flags and kill switches reduce rollout blast radius. Recovery objectives remain conditional on verified provider configuration such as PITR; the platform does not publish an unverified RPO as a guarantee.
release change
→ staged rollout
→ monitor errors and payment funnel
→ kill switch or rollback when abort criteria fireSource: docs/DISASTER_RECOVERY.md, docs/BACKUP_RULES.md, docs/ROLLOUT_RULES.md
Technical or integration questions? integration@bookingbible.com
Data-subject workflows cover access, correction, export, objection and deletion across core profile and venue records. Deletion retains records where a documented legal exception applies. Marketing and analytics paths consult consent and suppression gates, and retention jobs apply the configured policy.
const consent = await hasActiveConsent(userId, 'marketing_email');
if (!consent) {
return { skipped: true, reason: 'no_consent' };
}Source: src/lib/legal, src/lib/marketing, docs/COMPLIANCE_RULES.md
DPA acceptance is versioned, the sub-processor register is public, and material processing changes follow the contract’s notice mechanics. Incident records support assessment and communication; the GDPR 72-hour rule is applied when the legal notification threshold is met rather than treated as a blanket promise for every alert.
processing change
→ update registry and assessment
→ apply contractual notice
→ retain acknowledgement evidenceSource: /dpa, /legal/sub-processors, docs/INCIDENT_RESPONSE.md
Security issues go to security@bookingbible.com. The machine-readable policy at /.well-known/security.txt contains the current contact, encryption and expiry details. Booking Bible coordinates disclosure timing with the reporter and affected parties.
curl https://bookingbible.com/.well-known/security.txtSource: /.well-known/security.txt, docs/security/PENTEST_SCOPE.md
GDPR or DPA questions? dpo@bookingbible.com
Still have questions? support@bookingbible.com
Found something? Email security@bookingbible.com. Current disclosure and encryption details are published at /.well-known/security.txt. We coordinate disclosure timing with the reporter and affected parties.
Acknowledgments. Published credits are added with the reporter's consent when a validated report results in a fix.
Strictly necessary cookies keep the site working. With your consent we use analytics and marketing cookies to improve the experience and measure ad performance. You can change this any time from your account’s privacy settings.