Tenant isolation
Supabase row-level security and church-scoped membership checks restrict personal and church records. Negative tests cover cross-church and normal-member access.
Security should be a property of the system, not a promise.
Veil handles confessions, prayer and church records. This page distinguishes controls that exist today from work still required. It is not a certification, penetration-test report or claim of perfect security.
Implemented controls
Identity–content separation
The anonymous confession-review table has no user_id column. Review content cannot be joined back to an account through that table.
Server-owned authority
Entitlements, quotas, Stripe price allowlists and privileged database credentials are enforced server-side. Service-role credentials are not shipped to browsers.
Audited exceptional access
Operator review uses a restricted RPC that records actor, reason, time and target. Ordinary authenticated users cannot call it.
Payment integrity
Stripe webhook signatures use timing-safe comparison and replay tolerance. Veil stores payment identifiers, not raw card numbers.
Abuse and request controls
Sign-up, AI, account-data, notification and checkout paths use server-side authentication, authorisation and/or database-backed rate limits.
Browser and transport baseline
Production uses HTTPS/HSTS, clickjacking denial, MIME sniffing protection, restrictive referrer and browser-permission policies, and cross-origin opener/embedder/resource boundaries. OAuth popups remain allowed. External web-font requests have been removed.
User control
Authenticated users can export and delete personal records. Optional consent choices can be withdrawn and withdrawal times are recorded.
Important boundaries
Veil does not claim end-to-end encryption across every store, complete anonymity, SOC 2, ISO 27001, or a completed independent penetration test. Ordinary reflection and abuse-prevention logs do not send confession originals; operators see only minimal safety signals and encryption or processing status. Content that a user explicitly attaches to a support request is handled as a separate submission.
- An enforced Content Security Policy limits scripts and connections to Veil, the Supabase SDK/API and optional PostHog analytics. Legacy inline scripts still require
'unsafe-inline'; moving them to hashed or nonced scripts remains hardening work. - The service is a public beta and has not completed an external security audit.
- The Free response runs on-device. Gemini remains blocked from sensitive input by a default-deny privacy guard until the paid tier and its data terms are verified.
- Backup deletion timing, regional processing and incident procedures must be contractually verified before larger church deployments.
Report a vulnerability
Email security@veildaily.com with “Veil security report” in the subject. Include the affected URL or component, impact, reproduction steps and any minimal proof. Encrypt sensitive details before sending if possible; request a secure channel in the first message.
Research rules
- Use only accounts and data you own or have explicit permission to test.
- Do not access, change, retain or disclose another person’s confession, journal, church or payment data.
- Do not perform denial-of-service, spam, social engineering, physical attacks, automated high-volume scanning or provider-infrastructure testing.
- Stop when you demonstrate impact. Do not establish persistence or move laterally.
- Allow a reasonable remediation period before public disclosure and coordinate disclosure timing with us.
We aim to acknowledge a valid report within 3 business days and provide an initial assessment within 10 business days. These are public-beta targets, not guaranteed service levels. There is currently no paid bug-bounty programme.
Scope
In scope: veildaily.com and Veil-owned code served from it. Out of scope: Vercel, Supabase, Stripe, Google, PostHog, getBible and other third-party infrastructure; report issues in those services to their owners.
Security contact record
The machine-readable disclosure policy is at /.well-known/security.txt. Privacy rights and subprocessor information are in the privacy policy; church contract controls are in the DPA template.