| Version | Supported |
|---|---|
| 2.x | ✅ |
| < 2.0 | ❌ |
Policy: Only the latest major version receives security updates. When a new major version is released, prior major versions are immediately unsupported.
We take security seriously. If you discover a security vulnerability, please follow these steps:
- DO NOT open a public issue
- Send details via GitHub Security Advisories
- Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
-
Use Authentication for HTTP Transport
- Enable bearer token authentication when exposing the server over HTTP
- Set
MCP_AUTH_PROVIDER=simple_tokenand configureMCP_AUTH_TOKEN - Authentication is not required for stdio transport (local only)
-
Use TLS in Production
- The server does not terminate TLS natively
- Deploy behind a TLS-terminating reverse proxy (nginx, Caddy, Traefik) for any network-accessible deployment
-
Protect Database Credentials
- Use environment variables or secrets management for PostgreSQL and Supabase connection strings
- Never hardcode database credentials in configuration files
-
Container Security
- The official Docker image runs as non-root (UID 10001)
- Use read-only filesystem mounts where possible
- Follow the principle of least privilege for container permissions
-
Never Commit Secrets
- API keys
- Passwords
- Database connection strings
- Private certificates
-
Validate Input
- Prevent SQL injection via parameterized queries
- Validate and sanitize all tool parameters
- Use centralized configuration management for credentials
-
Use Secure Defaults
- Restrictive default configuration
- Opt-in for network exposure (stdio is default, HTTP requires explicit configuration)
- Explicit permissions over wildcards
Security patches will be released as soon as possible after discovery. Watch this repository for updates.
This project aims to follow security best practices including:
- OWASP guidelines where applicable
- Principle of least privilege
- Defense in depth
- Secure by default