PrintHive has undergone a comprehensive security audit. This document outlines our security practices and vulnerability handling procedures.

• Path Traversal Protection: All file paths validated with sanitizeFilePath() function
• HTML Escaping: User input escaped with htmlEscape() to prevent XSS attacks
• SQL Injection Prevention: All database queries use parameterized statements
• File Upload Validation: Only .stl, .3mf, and .gcode files accepted

• Session-based authentication required for all protected endpoints
• OAuth/OIDC SSO integration support (Authentik, etc.)
• Share links use cryptographically random hashes (16 bytes)
• Share link expiration enforced (24-hour TTL)
• Role-based access control (admin, user roles)

• ✓ No hardcoded credentials or secrets in codebase
• ✓ Environment variables properly used for all sensitive config
• .env file excluded from git via .gitignore
• SESSION_SECRET, OAUTH_CLIENT_SECRET, etc. configured via environment
• Database credentials managed securely

X-Frame-Options: SAMEORIGIN              (Clickjacking protection)
X-Content-Type-Options: nosniff           (MIME type sniffing prevention)
X-XSS-Protection: 1; mode=block           (Legacy XSS filter)
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: restricted       (Only self + trusted CDNs)
Permissions-Policy: disabled              (Camera, mic, geolocation, etc.)

• Zero npm vulnerabilities (verified with npm audit)
• Transitive dependencies pinned to secure versions
• Regular dependency updates via Dependabot

• Express app trusts proxy headers for X-Forwarded-*
• HTTPS recommended in production (via reverse proxy like Nginx)
• CORS properly configured where needed
• Session cookies marked as httpOnly and secure

• Share access tracking (for monitoring)
• No telemetry or usage tracking
• Database encryption recommended for sensitive deployments
• User data stored locally (not sent to third parties)

• Debug logs removed from production code (console.log/debug stripped)
• Console.error/warn retained for monitoring
• Type-safe database operations
• Proper error handling without leaking internals

• Alpine Linux base image (minimal attack surface)
• Non-root user execution
• Read-only filesystem where possible
• Security vulnerability scanning in CI/CD
• Health checks configured

• .gitignore excludes:
  • .env files
  • Database files (.db)
  • Session data
  • Application data directories
  • Sensitive logs

• /api/library/* (upload, list, edit metadata)
• /api/settings/* (user settings, printer config)
• /admin/* (admin panel)
• /api/log-level (log configuration)

• /library/share?hash=* (share page view)
• /api/library/share/:hash/download (download model)
• /api/library/share/:hash/geometry (3D geometry)
• /api/library/share/:hash/thumbnail (preview image)

If you discover a security vulnerability in PrintHive, please email security concerns to the maintainers or create a private security advisory on GitHub. Please do NOT create public issues for security vulnerabilities.

1. Report the vulnerability privately
2. Allow 90 days for patch development
3. Vulnerability will be disclosed after patch release
4. Security advisory will credit researchers (if desired)

# Generate a strong SESSION_SECRET
SESSION_SECRET=$(openssl rand -base64 32)

# Set PUBLIC_URL to your actual domain
PUBLIC_URL=https://printhive.example.com

# Configure OAuth if using SSO
OAUTH_PROVIDER=oidc
OAUTH_ISSUER=https://auth.example.com
OAUTH_CLIENT_ID=your-client-id
OAUTH_CLIENT_SECRET=your-client-secret

server {
    listen 443 ssl http2;
    server_name printhive.example.com;
    
    # SSL certificates (use Let's Encrypt)
    ssl_certificate /etc/letsencrypt/live/printhive.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/printhive.example.com/privkey.pem;
    
    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

• Back up database regularly
• Encrypt database backups
• Use strong passwords for local database access
• Run database in read-only mode where applicable

• Keep Node.js and dependencies updated
• Monitor logs for suspicious activity
• Review user accounts and permissions regularly
• Update Docker base image regularly

• Limit admin account creation
• Use strong passwords or SSO
• Enable MFA if available through OAuth provider
• Regularly audit user roles

1. Rate Limiting: Not implemented - should be added at reverse proxy level
2. Database Encryption: Application-level encryption not implemented - use full-disk encryption
3. Audit Logging: Limited - consider implementing detailed audit trails
4. DDOS Protection: Rely on reverse proxy and CDN
5. Backup Integrity: Verify backups regularly

Future security improvements planned:

• Rate limiting middleware
• Request signing for API calls
• Database-level encryption
• Comprehensive audit logging
• Security key/WebAuthn support
• Automatic vulnerability scanning in CI/CD

• OWASP Top 10
• Node.js Security Best Practices
• Express Security
• CWE-79: Cross-site Scripting
• CWE-89: SQL Injection

January 13, 2026 - Comprehensive security audit completed