👉 Full documentation — axiodb.in: security model, RBAC, TCP authentication, and password policy. Also see CONTRIBUTING.md for how to contribute.

We actively support the following versions of AxioDB with security updates. Please ensure you are using a supported version to receive critical security patches and updates.

Recommendation: Always use the latest version of AxioDB for the best security, performance, and features.

npm install axiodb@latest

AxioDB includes several security features to protect your data:

• File Isolation: Each document stored in separate files with proper permissions
• Secure Defaults: Security-first configuration out of the box
• No External Dependencies: Reduces attack surface (pure JavaScript)

We take security seriously and appreciate the security community's efforts to responsibly disclose vulnerabilities. If you discover a security issue in AxioDB, please report it through one of the following channels:

1. Navigate to the AxioDB GitHub repository
2. Go to the "Security" tab
3. Click "Report a vulnerability"
4. Fill out the form with details

Send an email to ankansahaofficial@gmail.com with:

• Subject: [SECURITY] AxioDB Vulnerability Report
• Description: Clear description of the vulnerability
• Steps to Reproduce: Detailed steps to reproduce the issue
• Impact: Potential security impact and affected versions
• Suggested Fix: (Optional) Your suggestions for fixing the issue

Please include the following information in your report:

• Type of vulnerability (e.g., XSS, CSRF, SQL Injection equivalent, etc.)
• Full paths of source file(s) related to the vulnerability
• Location of the affected source code (tag/branch/commit or direct URL)
• Any special configuration required to reproduce the issue
• Step-by-step instructions to reproduce the issue
• Proof-of-concept or exploit code (if possible)
• Impact of the issue, including how an attacker might exploit it

• Initial Response: Within 48 hours of receiving your report
• Status Update: Within 7 days with assessment and planned fix timeline
• Fix Development: Depending on severity and complexity
• Disclosure: Coordinated disclosure after fix is released

1. Triage: We assess the severity and impact of the reported vulnerability
2. Fix Development: We develop and test a fix in a private repository
3. Release: Security fixes are released as patch versions (e.g., 22.17.2)
4. Disclosure: After release, we publish a security advisory with details
5. Credit: We credit researchers who responsibly disclose vulnerabilities (unless they prefer to remain anonymous)

We use the following severity levels for security issues:

When using AxioDB in production:

AxioDB is schema-less and does not validate document structure — validate and sanitize untrusted input in your application code before calling insert():

function isValidUser(doc) {
  return (
    typeof doc.email === 'string' && /\S+@\S+\.\S+/.test(doc.email) &&
    typeof doc.age === 'number' && doc.age >= 0 && doc.age <= 150 &&
    typeof doc.name === 'string' && doc.name.length > 0 && doc.name.length <= 100
  );
}

if (isValidUser(userInput)) {
  await collection.insert(userInput);
}

Restrict file system access to the AxioDB data directory:

# Linux/macOS
chmod 700 ./AxioDB

Regularly update to the latest version:

npm update axiodb

• Watch the GitHub repository
• Subscribe to npm security advisories
• Check the SECURITY.md file regularly

AxioDB is designed for embedded, single-instance use cases:

• ✅ Desktop applications (Electron, Tauri)
• ✅ CLI tools
• ✅ Local-first applications
• ⚠️ Not recommended for public-facing web servers without additional security layers
• ⚠️ Not designed for multi-tenant cloud deployments

AxioDB stores data in the file system:

• Ensure proper file permissions on the data directory
• Do not expose the data directory via web servers
• Implement regular backups

The built-in GUI (localhost:27018) and AxioDBCloud TCP server (port 27019) share a single role-based access control system:

• ✅ Role-based access control (Super Admin / Admin / View) shared by the GUI and TCP server
• ✅ A seeded admin account is forced to change its password (mustChangePassword) before any protected GUI route or authenticated TCP command will work — unless the server was started with AdminPassword (AXIODB_ADMIN_PASSWORD in Docker), which seeds the account ready to use
• ⚠️ The forced change can only be completed through the HTTP API/GUI, so a server with TCP authentication and no HTTP surface has no recovery path. The CLI (axiodb serve tcp-auth) and the Docker image both refuse to start in that state rather than come up with a port nobody can log into
• ⚠️ TCP authentication is opt-in via TCPAuth: true (or AXIODB_TCP_AUTH_ENABLED=true in Docker, which is the container's default) - without it, any client that can reach the TCP port has full database access over an unencrypted protocol
• ⚠️ Do not expose the GUI or TCP port to public networks without your own TLS termination
• ✅ Safe for Electron apps and local development (binds to localhost by default)

• We follow coordinated disclosure principles
• Security fixes are released before public disclosure
• We provide credit to researchers who report vulnerabilities responsibly
• Public disclosure is made after fixes are available and users have time to update

For security-related questions or concerns:

• Email: ankansahaofficial@gmail.com
• GitHub: Report a vulnerability

We recognize and thank the following security researchers who have helped improve AxioDB's security:

No vulnerabilities reported yet.

Thank you for helping keep AxioDB and its users safe! 🛡️