Trust Center

Security at OhoLingo is an ongoing discipline—not a certificate on a wall. We design the product with sensible defaults, minimize sensitive surface area, and rely on mature cloud providers so we can focus on teaching experiences that stay fast, private, and reliable for learners everywhere.

This Trust Center explains how we think about infrastructure, data, authentication, application protections, and vendor relationships. It is descriptive of our architecture and practices; it is not a legal agreement—please refer to our Privacy Policy and Terms of Service for contractual terms.

The OhoLingo web application is hosted on Vercel, which provides a global content delivery network, automatic HTTPS, and edge protection features appropriate to modern web applications. This helps ensure low latency for learners, consistent TLS, and platform-level DDoS mitigation typical of leading edge networks.

We configure deployments to follow secure networking expectations: traffic is terminated with modern TLS versions and cipher practices suitable for production SaaS delivery. Internal administrative access follows least-privilege principles appropriate to a small, accountable team.

Diagram is illustrative. Actual deployment topologies may include staging environments, additional caching, and provider-specific controls not shown here.

Encryption in transit: Connections to oholingo.com and related APIs use HTTPS so data moving between your browser and our services is protected with industry-standard transport encryption.

Encryption at rest: Stored application data benefits from encrypted storage primitives provided by our managed database and object storage vendors, reducing risk from physical media issues in provider data centers.

Database security: We model learner-owned data with Row Level Security–oriented patterns on Supabase so application roles cannot casually read other users’ progress without explicit authorization.

Backups & continuity: Our cloud providers include backup and redundancy features appropriate to managed Postgres. We aim for restore procedures proportional to a learning product—detailed enterprise recovery targets can be discussed for institutional customers.

Authentication is powered by Supabase Auth with patterns aligned to server-side rendering: sessions are handled with secure, HTTP-only cookies where configured so tokens are not exposed to JavaScript unnecessarily.

Email verification: Account verification and sensitive changes use email confirmation flows to reduce takeover risk and keep recovery predictable.

Social login: Where OAuth providers are enabled, we delegate credential handling to those providers and receive scoped tokens suitable for linking an account—never your third-party password.

Session management: Sessions expire and rotate according to provider and application configuration. We avoid verbose client logging of session material in production builds.

MFA readiness: Additional authentication factors are part of our product roadmap for teams and institution administrators who require stronger assurance than passwords alone.

Input validation: User input is validated on the server wherever data crosses a trust boundary—lessons, profiles, and authoring flows reject malformed payloads before they touch persistence layers.

Rate limiting & abuse prevention: High-risk endpoints receive throttling and heuristics to deter automated abuse while keeping legitimate learners productive.

Secure headers: We adopt modern HTTP security headers (such as content type and frame protections) appropriate to Next.js deployments to reduce common web attack classes.

CSRF, XSS, and injection: Framework defaults, templating, and parameterized queries mitigate cross-site scripting, cross-site request forgery on cookie-authenticated operations, and SQL injection against our Postgres APIs.

GDPR readiness: We design processes and documentation for European and global privacy expectations: lawful basis transparency, data minimization in product analytics, and clear channels for questions.

Cookie consent: Non-essential analytics and marketing scripts honor your choices via our cookie banner and consent APIs—see our Cookie Policy for categories.

Privacy controls: In-product settings and account tools evolve alongside the platform; refer to the Privacy Policy for the authoritative list of rights (such as access, correction, and deletion) and how to exercise them.

• GDPR-aware design

  Privacy notices, consent flows, and configurable controls.

• Cookie consent

  Non-essential scripts respect regional preferences.

• Data subject tools

  Rights described in our Privacy Policy; workflows evolve with the product.

• Tenant isolation mindset

  RLS-oriented data models for user-owned records.

• Account verification

  Email confirmation for sensitive account changes where enabled.

• Vendor due diligence

  Critical providers are chosen for operational maturity.

Monitoring & alerting: Production environments emit logs and metrics that help the team notice spikes in errors, unusual traffic, or availability regressions early.

Audit trails: Administrative and security-sensitive actions are logged where practicable so investigations can reference traceable evidence.

Incident response: When an incident is suspected or confirmed, we follow a contained workflow: assess impact, mitigate immediate risk, communicate to affected users when warranted, document root causes, and ship durable fixes. Enterprise customers may receive advance notice of material events as contractually agreed.

Like most SaaS products, OhoLingo depends on specialized vendors. We select providers with strong operational reputations and govern them through organizational review, least-privilege access, and contractual expectations where applicable.

• Use a unique password and a reputable password manager.
• Watch for phishing domains that mimic OhoLingo—we only communicate from verified domains you recognize.
• Keep your email inbox secured; password resets land there.
• Sign out on shared devices and avoid installing unknown browser extensions that read page content.

If you believe you have found a security vulnerability, please tell us. We welcome good-faith research that avoids user harm, data destruction, or service disruption.

Include concise reproduction steps, affected components, and your assessment of impact. We aim to acknowledge valid reports and work toward remediation timelines proportional to severity.