We release patches for security vulnerabilities in the following versions:
| Version | Supported |
|---|---|
| 1.3.x | ✅ |
| 1.2.x | ✅ |
| < 1.2 | ❌ |
We take the security of Sellf seriously. If you believe you have found a security vulnerability, please report it to us as described below.
Please do not report security vulnerabilities through public GitHub issues.
Please report security vulnerabilities using GitHub Security Advisories.
Include the following information:
- Type of vulnerability (e.g., XSS, SQL injection, authentication bypass)
- Full paths of source file(s) related to the vulnerability
- Location of the affected source code (tag/branch/commit or direct URL)
- 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
- Acknowledgment: We will acknowledge receipt of your vulnerability report within 48 hours
- Assessment: We will assess the vulnerability and determine its severity
- Fix Timeline: Critical vulnerabilities will be addressed within 7 days; high-priority within 30 days
- Disclosure: We will coordinate with you on the disclosure timeline
- Credit: We will credit you in our release notes (if you wish)
Sellf implements comprehensive security measures:
- Authentication: Supabase Auth with magic link and OAuth support
- Authorization: Row Level Security (RLS) policies on all database tables
- Rate Limiting: Multi-layer rate limiting with anti-spoofing (server-side IP only)
- Input Validation: Zod schemas for all API inputs
- SQL Injection Prevention: Parameterized queries throughout
- XSS Protection: Content sanitization and CSP headers
- CSRF Protection: Custom header requirements for API calls
- Encryption: AES-256-GCM for API keys and sensitive data
- Audit Logging: Comprehensive logging of admin actions
- Payment Security: PCI-compliant Stripe integration
Security updates are released as patch versions (e.g., 1.0.1, 1.0.2). Subscribe to our releases to stay informed:
- Watch this repository for new releases
- Check our BACKLOG.md for security-related items
When deploying Sellf:
-
Environment Variables: Never commit secrets to version control
-
Database: Use strong passwords and restrict network access
-
API Keys: Rotate keys regularly and use minimal scopes
-
Updates: Keep dependencies up to date
-
HTTPS: Always use HTTPS in production
-
Backups: Maintain regular database backups
-
Monitoring: Set up logging and alerting
-
Reverse proxy +
TRUSTED_PROXY=true: SetTRUSTED_PROXY=truein production and serve the Node process behind a reverse proxy (Caddy/nginx/Cloudflare) that appends the real client IP toX-Forwarded-For. Production refuses to boot without it.Without a reverse proxy (e.g. local dev) the rate limiter falls back to a fingerprint built from
User-Agent/Accept-Language/Accept, which a determined attacker can rotate to dilute the bucket. This is an accepted dev-mode limitation, not a production deploy mode.
All identified security vulnerabilities have been addressed. For the security posture of the current version, see our test suite (1500+ tests with 100% pass rate).
This security policy applies to:
- Sellf Admin Panel (
admin-panel/) - MCP Server (
mcp-server/) - Database migrations (
supabase/migrations/) - Sellf SDK (
sellf.js)
Last Updated: 2026-03-07