Wildbox Security Policy & Best Practices

Last Updated: November 7, 2024 Status: Secure Foundation Established - Ready for Community Evaluation Version: 2.0 Maturity: Early Evaluation Phase

Critical Security Requirements
Security Features Implemented
Security Incident Contacts
Additional Resources
Version History

CRITICAL SECURITY REQUIREMENTS

Before Production Deployment

NEVER deploy Wildbox to production without completing ALL security requirements below!

Recent Security Improvements (2024)

✓ Fixed critical eval() RCE vulnerability
✓ Resolved 13 Dependabot security alerts
✓ Implemented security headers middleware
✓ Fixed CORS configuration across all services
✓ Added authentication to critical endpoints
✓ Removed default secrets from docker-compose
✓ Created comprehensive security documentation
✓ Implemented environment-based configuration

1. Environment Variables Configuration

Copy .env.example to .env and configure all variables:

cp .env.example .env

Required changes:

Generate secure random values for all keys and passwords
Change all default credentials
Use strong, unique passwords for all services
Configure proper CORS origins for your domain

2. Critical Security Variables to Change

Variable	Description	Security Level
`JWT_SECRET_KEY`	JWT token signing key	CRITICAL
`INITIAL_ADMIN_PASSWORD`	Default admin password	CRITICAL
`POSTGRES_PASSWORD`	Database password	CRITICAL
`API_KEY`	Main API authentication key	CRITICAL
`STRIPE_SECRET_KEY`	Payment processing key	CRITICAL
`ENCRYPTION_KEY`	Data encryption key	CRITICAL

3. Password Security Requirements

Minimum 16 characters
Mix of uppercase, lowercase, numbers, symbols
No dictionary words
Unique per service
Rotated regularly

4. Secure Key Generation

Use secure random generators:

# Generate JWT secret (64 characters)
openssl rand -base64 48

# Generate API key
openssl rand -hex 32

# Generate encryption key
openssl rand -base64 32

# Generate secure password
openssl rand -base64 24

5. Production Security Checklist

6. Network Security

Required Firewall Rules

Port 22: SSH access (restrict to admin IPs only)
Port 80/443: HTTP/HTTPS (public, with proper SSL)
Port 5432: PostgreSQL (internal network only)
Port 6379: Redis (internal network only)
All other ports: Blocked from external access

SSL/TLS Configuration

Use Let’s Encrypt or commercial SSL certificates
Enable HTTP to HTTPS redirect
Configure strong cipher suites
Enable HSTS headers

7. Database Security

PostgreSQL Hardening

-- Create dedicated user for application
CREATE USER wildbox_app WITH PASSWORD 'secure_random_password';

-- Grant minimal required permissions
GRANT CONNECT ON DATABASE wildbox_main TO wildbox_app;
GRANT USAGE ON SCHEMA public TO wildbox_app;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO wildbox_app;

-- Remove default postgres user access if not needed

Redis Security

Enable authentication (requirepass directive)
Bind to localhost only unless clustering
Disable dangerous commands (rename-command directive)

8. Application Security

Authentication

Enable MFA for admin accounts
Set session timeouts (default: 1 hour)
Implement account lockout after failed attempts
Require email verification for new accounts

API Security

Rate limiting enabled on all endpoints
API key rotation every 90 days
Input validation on all user inputs
SQL injection protection via parameterized queries

9. Monitoring & Logging

Required Monitoring

Authentication failures
Unauthorized access attempts
Database connection anomalies
High resource usage
Service health status

Log Requirements

Centralized logging (ELK stack, Splunk, etc.)
Log retention policy (minimum 90 days)
Log integrity protection
Automated alerting on security events

10. Backup & Recovery

Backup Strategy

Daily automated backups of all databases
Encrypted backup storage
Off-site backup replication
Regular restore testing
Recovery time objective: < 4 hours
Recovery point objective: < 1 hour

11. Incident Response

Preparation

Document incident response procedures
Define roles and responsibilities
Establish communication channels
Create contact lists for emergencies
Regular tabletop exercises

12. Compliance Considerations

Depending on your use case, ensure compliance with:

GDPR (EU data protection)
SOC 2 (security controls)
ISO 27001 (information security)
NIST Cybersecurity Framework
Industry-specific regulations

13. Managing Dependency Vulnerabilities

Wildbox uses GitHub Dependabot for continuous security scanning of all dependencies.

Transitive Dependencies (Current Status):

10 security alerts exist from transitive dependencies (upstream packages)
These are not code vulnerabilities - they exist in libraries we depend on
We cannot fix them directly - they require upstream package patches
See GitHub Security Alerts for real-time status

Mitigation Strategy:

Dependabot enabled: Automatically detects new vulnerability patches
Automated PRs: Creates pull requests when patched versions available
Testing integration: Full test suite validates compatibility
Automatic merging: Patches integrated immediately when tests pass (typically within 1-4 weeks)

Your Deployment Considerations:

For Development/Testing: Use docker-compose up -d as-is for evaluation
For Staging: Monitor GitHub Security Alerts page
For Production:
- Wait for upstream patches (usually released within weeks of disclosure)
- Check our releases page for updates
- Subscribe to GitHub Security Advisories
- Join our GitHub Discussions for security updates

Best Practices:

Keep Docker images updated with docker-compose build --pull
Monitor GitHub Security tab for patch availability
Test patches in staging before production deployment
Report any real-world vulnerability impacts you discover

Security Features Implemented

1. Authentication & Authorization

JWT tokens with HS256 encryption (minimum 32-char secret)
bcrypt password hashing (12+ rounds)
Bearer token authentication on all protected endpoints
API key support for service-to-service communication
Role-based access control (RBAC)
Token expiration and refresh mechanisms

2. API Security

Restricted CORS (environment-configured, never wildcard)
Security headers: HSTS, X-Frame-Options, X-Content-Type-Options, CSP
Input validation on all endpoints
Parameterized queries (no SQL injection)
XXE protection (defusedxml)
Rate limiting ready (slowapi)

3. Code Security

No eval() calls (secure JSON serialization)
No hardcoded secrets in code
No plaintext password logging
Secure random generation for tokens/keys
Error handling without exposing internals

4. Infrastructure Security

Secrets required (no defaults in docker-compose)
Environment-based configuration
TLS/SSL support
Network segmentation
Health checks configured
Monitoring hooks ready

Security Incident Contacts

If you discover a security vulnerability:

Do NOT create a public issue
Email security team at: fabrizio.salmi@gmail.com
Include detailed reproduction steps
Provide your contact information
Allow 48 hours for initial response

Bug Bounty Program

We value security researchers! Valid vulnerability reports receive:

Critical: Recognition + merchandise
High: Recognition
Medium: Recognition
Low: Acknowledgment

Additional Resources

Last Updated: November 7, 2024 Version: 2.0 Review Frequency: Quarterly Next Review: February 7, 2025

Version History

2.0 (November 7, 2024)

Fixed critical eval() RCE vulnerability
Resolved 13 Dependabot security alerts
Implemented comprehensive security headers middleware
Fixed CORS configuration across all services
Added authentication to critical endpoints
Removed all default secrets from docker-compose.yml
Created shared authentication utilities
Added production deployment guidance

1.0 (October 2024)

Initial security policy and best practices guide