Back to home

Security

Last updated: May 2026

Security is a core design principle at otomoAI. We apply defence-in-depth across every layer of the platform — from authentication and data storage to API communication and operational practices. This page summarises our current security posture.

Infrastructure & Network Security

  • HTTPS everywhere: All traffic is encrypted in transit using TLS 1.2+, with TLS 1.3 preferred. HTTP requests are automatically redirected to HTTPS.
  • Cloudflare edge: The platform is served behind Cloudflare, providing DDoS mitigation, WAF protection, and rate limiting at the network edge.
  • Serverless API: Backend logic runs as isolated Cloudflare Pages Functions — no persistent server process reduces the attack surface.

Authentication & Access Control

  • JWT authentication: All API requests are authenticated with short-lived JSON Web Tokens issued by Supabase Auth.
  • Multi-factor authentication (MFA): MFA via TOTP authenticator apps is available and strongly recommended for all users.
  • OAuth 2.0: Google sign-in uses the standard OAuth 2.0 authorisation code flow. We never receive or store your Google password.
  • Row-Level Security (RLS): Supabase RLS policies enforce tenant data isolation at the database layer — users can only access their own organisation's data.
  • Service role isolation: The Supabase service role key is used exclusively server-side within Cloudflare Functions. It is never exposed to the browser.

Data Encryption

  • In transit: All data exchanged between your browser, our API, and third-party services is encrypted with TLS 1.3.
  • At rest: Data stored in Supabase (PostgreSQL) is encrypted at rest using AES-256 managed by the cloud provider.
  • Secrets management: API keys, webhook secrets, and credentials are stored as encrypted environment variables in Cloudflare — never hardcoded in source code.

Webhook & API Security

  • HMAC signature verification: All inbound webhooks (e.g., Billplz payment callbacks) are verified using HMAC-SHA256 signatures before processing.
  • Outbound webhook signing: Outbound requests to n8n and other internal systems are signed with HMAC-SHA256 to prevent tampering.
  • Rate limiting & pagination bounds: API endpoints enforce rate limits and capped pagination to prevent abuse and data exfiltration.
  • Idempotency keys: Payment and document operations use idempotency controls to prevent duplicate processing.

Monitoring & Incident Response

  • Error tracking: Sentry monitors application errors and performance anomalies in real time.
  • Audit logging: Security-relevant events (logins, permission changes, payment actions) are written to immutable audit logs.
  • Incident response: We maintain an internal incident response process. Critical security issues are prioritised for same-day remediation.

Compliance

  • PDPA Malaysia: We process personal data in accordance with Malaysia's Personal Data Protection Act 2010. See our Privacy Policy for full details.
  • OWASP standards: Our development and security review processes follow OWASP Top 10 guidelines to address the most critical web application security risks.
  • Dependency management: Third-party dependencies are regularly reviewed and updated to address known vulnerabilities.

Responsible Disclosure

We welcome responsible disclosure of security vulnerabilities. If you discover a potential security issue in our platform, please report it privately before making it public so we have the opportunity to investigate and remediate.

Report a vulnerability

Email: enquiry@otomoai.com.my

Subject line: [Security Report] Brief description

We commit to acknowledging your report within 72 hours and providing a resolution timeline. We will not take legal action against researchers who act in good faith and follow responsible disclosure practices.

Contact

For general security questions or to report a non-critical issue:

otomoAI Security
Malaysia
Email: enquiry@otomoai.com.my