nessi
d694c8b8e3
Add .env.example with configuration for database, Redis, security, SMTP, workers, and plugins. Add .gitignore for Python, Node.js, Next.js, Docker volumes, and IDE files. Add MIT License. Update README.md with feature overview, quick start guide, architecture description, plugin system documentation, security details, backup/restore instructions, and developer setup. Add Alembic configuration files and placeholder directories for API, web, worker, and plugin components
82 lines
2.6 KiB
Markdown
82 lines
2.6 KiB
Markdown
# NexaDash Security Documentation
|
|
|
|
This document describes the security architecture and configuration recommendations for NexaDash.
|
|
|
|
## Authentication
|
|
|
|
- Passwords are hashed with **Argon2id**.
|
|
- Sessions use short-lived JWT access tokens (15 minutes) and long-lived refresh tokens (7 days) stored in HTTP-only cookies.
|
|
- Failed logins are rate-limited and accounts are locked after repeated failures.
|
|
|
|
## Authorization
|
|
|
|
- Role-based access control (RBAC) with system roles: Owner, Admin, Editor, Viewer.
|
|
- Permissions are enforced on every API endpoint.
|
|
- Owners bypass permission checks but their actions are still audit-logged.
|
|
|
|
## Secrets
|
|
|
|
- All service credentials are encrypted with Fernet (AES-128-CBC + HMAC) before storage.
|
|
- Secrets are only decrypted by the backend connector layer.
|
|
- The encryption key must be set via `NEXADASH_ENCRYPTION_KEY` and never exposed to the frontend.
|
|
|
|
## Input Validation
|
|
|
|
- All API inputs are validated with Pydantic schemas.
|
|
- SQLAlchemy ORM prevents SQL injection.
|
|
- Service URLs are validated against SSRF blocklists.
|
|
|
|
## Network Security
|
|
|
|
- Only `http` and `https` schemes are allowed for service URLs.
|
|
- Private IP ranges (10.0.0.0/8, 127.0.0.0/8, 192.168.0.0/16, 169.254.169.254) are blocked.
|
|
- Redirect following is disabled for outbound requests.
|
|
|
|
## Plugin Sandboxing
|
|
|
|
- Plugins are declarative JSON manifests.
|
|
- Custom connectors are loaded from a known registry; arbitrary Python code is not executed.
|
|
- Uploaded plugins are validated before installation.
|
|
- The plugin process runs with the same container restrictions but no direct filesystem access beyond the plugin directory.
|
|
|
|
## Security Headers
|
|
|
|
The API sets:
|
|
|
|
- `X-Content-Type-Options: nosniff`
|
|
- `X-Frame-Options: DENY`
|
|
- `Referrer-Policy: strict-origin-when-cross-origin`
|
|
- `Permissions-Policy`
|
|
- `Content-Security-Policy`
|
|
|
|
## Audit Logging
|
|
|
|
All critical actions are recorded in `audit_logs`:
|
|
|
|
- login/logout
|
|
- user create/update/delete
|
|
- role changes
|
|
- plugin install/activate/delete
|
|
- dashboard modifications
|
|
- connection changes
|
|
|
|
## Rate Limiting
|
|
|
|
- Default: 100 requests per minute.
|
|
- Login: 10 requests per minute.
|
|
- Configurable via environment variables.
|
|
|
|
## Recommendations
|
|
|
|
1. Change all default secrets in `.env` before deployment.
|
|
2. Use HTTPS in production.
|
|
3. Keep the app and dependencies updated.
|
|
4. Run container scans with Trivy or Docker Scout.
|
|
5. Restrict database and Redis access with Docker networks.
|
|
6. Enable database backups and test restores.
|
|
7. Use strong, unique API tokens for each service.
|
|
|
|
## Vulnerability Reporting
|
|
|
|
Report security issues privately to the maintainers.
|