Security

Security at OhoLingo

How we protect accounts, data, and payments: HTTPS, strict headers, Supabase RLS, rate limits, audit logging, and safe-by-default configuration.

• Transport and headers. All production traffic is served over HTTPS with HSTS preload–ready settings. We set strict Content-Security-Policy (nonce-based scripts), X-Content-Type-Options, frame denial, referrer policy, permissions policy, and cross-origin isolation headers appropriate for analytics and payments.
• Authentication. Passwords require at least 12 characters; we check breached-password corpora at signup (Have I Been Pwned k-anonymity). Sign-in, registration, and magic links are rate limited per IP. We use generic responses where needed to reduce account enumeration. Supabase Auth handles sessions, refresh rotation, and email verification flows.
• Authorization. Data access uses Supabase Row Level Security with deny-by-default posture. Staff roles are resolved server-side; client code must never be trusted for permissions.
• APIs and webhooks. State-changing routes validate JSON with strict schemas, limit body size, verify browser Origin where applicable, and apply sliding-window rate limits. Stripe webhooks verify signatures and deduplicate events by id.
• Logging. Security-relevant events are written to an append-only audit trail (service role only) for investigation and compliance workflows.
• Privacy and subprocessors. Analytics and marketing scripts load only after consent. See also our Privacy Policy and Trust Center.

Report vulnerabilities: hello@oholingo.com