Architecture & Safeguards

Security Standards

A factual review of the engineering safeguards, data masking, cryptographic hashing, and authorization controls implemented in MailBee AI.

Architecture Audit Date: October 24, 2026 · Systems Verified
Factual Security Disclosure: We believe in transparent engineering. Rather than making vague claims of "military-grade encryption" or unverified third-party certifications, this document outlines the exact technical controls running in our production codebase.

1. Cryptographic Password Hashing

User passwords are protected using the industry-standard scrypt key derivation function implemented via Node.js native cryptographic libraries:

  • Salt Generation: A unique, cryptographically random 16-byte salt is generated for every user upon registration.
  • Key Derivation: Passwords are derived with high CPU and memory hardness (N=16384, r=8, p=1, key length 64 bytes) to defend against GPU-accelerated rainbow table and brute-force attacks.
  • Zero Plaintext Storage: Passwords never touch the database disk in raw form. Only salt:hash strings are persisted.

2. Server-Side Data Masking

Protecting recruiter contact details from mass scraping or unauthorized client-side inspection is a core design requirement of MailBee AI:

  • No Client-Side Redaction: Many websites load full emails into the browser DOM and merely blur them with CSS. MailBee AI never does this.
  • Server-Level Redaction: When a user queries the recruiter catalog, the backend API sanitizes strings before emitting JSON over the wire (e.g., transforming priya.sharma@techcorp.in into p••••••••@techcorp.in). Full email and phone data exist only in server memory until an authorized unlock transaction completes.

3. ACID Transaction Integrity

Credit deductions and contact reveals must remain perfectly synchronized to prevent race conditions or duplicate billing:

  • Write-Ahead Logging (WAL): SQLite operates in WAL mode with full foreign-key constraints enabled.
  • Atomic Reveal Transactions: Contact reveal calls execute inside an explicit BEGIN TRANSACTION ... COMMIT block. The decrement of 1 user credit and the recording of the unlocked contact ID succeed together or fail together. If an error occurs, the transaction automatically issues a ROLLBACK.

4. Server-Enforced Role-Based Authorization

Security boundaries are strictly enforced on backend endpoints, never relying solely on frontend UI hiding:

  • Admin Access: Sensitive routes (e.g., viewing user support tickets, managing subscriber records) verify the authenticated user's role = 'admin' server-side. Non-admin tokens receive an immediate 403 FORBIDDEN status.
  • Owner Ticket Isolation: When regular users query support tickets, SQL queries constrain results to user_id = ? OR email = ?, guaranteeing users cannot read tickets submitted by others.

5. Abuse Prevention & Rate Limiting

To safeguard application performance and mitigate spam:

  • Form Rate Limiting: Endpoints for support ticket creation and partnership inquiries enforce rolling in-memory rate limits (maximum 5 requests per IP / user per 10 minutes).
  • Input Sanitation: All query parameters in search and filter workflows use parameterized SQL statements (e.g. db.prepare('... WHERE comp.name = ?')) to render SQL injection attacks impossible.

6. Responsible Vulnerability Disclosure

If you discover a security issue or vulnerability in MailBee AI, we invite you to report it responsibly:

  • Please send a detailed description with reproduction steps to security@mailbee.ai.
  • We acknowledge vulnerability disclosures within 24 business hours and prioritize swift remediation.