| Version | Supported |
|---|---|
| 1.x.x | ✅ |
We take security vulnerabilities seriously. If you discover a security issue, please report it responsibly.
- Do NOT create a public GitHub issue for security vulnerabilities
- Email the security report to: [security contact - to be configured]
- Or use GitHub's private vulnerability reporting feature
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
- Initial Response: Within 48 hours
- Status Update: Within 7 days
- Fix Timeline: Depends on severity
| Level | Description | Response Time |
|---|---|---|
| Critical | Remote code execution, data breach | 24-48 hours |
| High | Authentication bypass, privilege escalation | 7 days |
| Medium | Information disclosure, XSS | 14 days |
| Low | Minor issues | 30 days |
When self-hosting Wardrowbe, follow these recommendations:
- Generate strong secrets:
openssl rand -hex 32 - Never commit
.envfiles - Rotate secrets periodically
- Use different secrets for each environment
- Always use HTTPS in production
- Place behind a reverse proxy (nginx, Caddy, Traefik)
- Use firewall rules to limit exposure
- Consider VPN for admin access
- Use OIDC provider for multi-user deployments
- Enable MFA on your OIDC provider
- Regularly review user access
- Keep Docker images updated
- Monitor Dependabot alerts
- Subscribe to security advisories
- Regular database backups
- Store backups securely (encrypted)
- Test backup restoration
- Uploaded images are stored on disk
- Access controlled via user authentication
- Consider disk encryption for sensitive deployments
- AI requests may contain clothing images
- Use local AI (Ollama) for maximum privacy
- Review AI provider privacy policies if using cloud services
- Passwords are not stored (OIDC-based auth)
- Session tokens use secure JWT
- Database should be on private network
We appreciate security researchers who help keep Wardrowbe secure. Contributors will be acknowledged (with permission) in release notes.