⚠️ CRITICAL: SQLPulse has the capability to execute arbitrary SQL queries against connected databases. Improper configuration or access control can lead to data loss, unauthorized access, or other security incidents. Please read this document carefully and implement all recommended security measures.

We take the security of SQLPulse seriously. If you believe you have found a security vulnerability, please report it to us as described below.

⚠️ IMPORTANT: Please do NOT report security vulnerabilities through public GitHub issues.

To report a security vulnerability:

1. Preferred: Create a private security advisory in the GitHub repository

   • Go to the "Security" tab in the repository
   • Click "Report a vulnerability"
   • Fill out the security advisory form with as much detail as possible

2. Alternative: Contact the maintainer privately through GitHub

You should receive a response within 48 hours. If you don't receive a response, please follow up to ensure your report was received.

Please include the following in your report:

• Type of vulnerability
• 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 vulnerability, including how an attacker might exploit it

This information will help us triage your report more quickly.

We release patches for security vulnerabilities in the following versions:

NEVER:

• Commit .env files or any files containing secrets to version control
• Use default credentials in production
• Share encryption keys between environments
• Grant unnecessary database permissions
• Run the application with database admin/root accounts
• Expose the application directly to the internet without proper security measures

ALWAYS:

• Use HTTPS/SSL in production
• Implement proper network segmentation
• Enable audit logging
• Regularly review access logs
• Keep all dependencies up to date
• Follow the principle of least privilege

1. Environment Variables

   • Never commit .env files to version control
   • Use strong, randomly generated secrets:

     # Generate JWT_SECRET
     openssl rand -base64 32
     
     # Generate ENCRYPTION_KEY (exactly 32 characters)
     openssl rand -base64 32 | cut -c1-32

2. Default Credentials

   • Change the default admin password immediately after first login
   • Default credentials:
     • Email: admin@example.com
     • Password: admin123 (CHANGE THIS!)

3. Database Security

   • Use strong passwords for database users
   • Restrict database access to application servers only
   • Enable SSL/TLS for database connections in production
   • Regularly update PostgreSQL and Redis

4. Network Security

   • Use HTTPS in production (configure reverse proxy with SSL)
   • Restrict API access using CORS settings
   • Use firewall rules to limit access to services
   • Consider using a VPN for sensitive database access

5. Authentication & Authorization

   • JWT tokens expire after 7 days by default
   • Implement role-based access control (RBAC)
   • Monitor failed login attempts
   • Implement rate limiting on authentication endpoints

6. Data Encryption

   • Database credentials are encrypted using AES-256
   • Ensure ENCRYPTION_KEY is kept secure and backed up
   • Never share encryption keys between environments

1. Code Security

   • Never hardcode secrets in code
   • Use parameterized queries to prevent SQL injection
   • Validate and sanitize all user inputs
   • Implement proper error handling without exposing sensitive information

2. Dependencies

   • Regularly update dependencies: npm audit fix
   • Review security advisories: npm audit
   • Use package-lock.json to ensure consistent installations

3. Logging

   • Never log sensitive information (passwords, tokens, API keys)
   • Sanitize logs before external transmission
   • Implement log rotation and retention policies

4. API Security

   • All API endpoints require JWT authentication (except /auth/login and /auth/register)
   • Implement rate limiting on all endpoints
   • Validate request payloads against schemas
   • Use HTTPS in production

SQLPulse implements several security measures:

1. Authentication

   • JWT-based authentication with configurable expiry
   • Bcrypt password hashing (10 rounds)
   • Role-based access control (RBAC)

2. Data Protection

   • AES-256 encryption for database credentials
   • Environment-based configuration
   • Secure session management

3. Database Security

   • Parameterized queries (Sequelize ORM)
   • Connection pooling with limits
   • Encrypted password storage

4. API Security

   • JWT token verification middleware
   • CORS configuration
   • Request validation
   • Error handling without information leakage

HIGH RISK: Users with query execution permissions can run ANY SQL command on connected databases, including:

• DROP TABLE / DROP DATABASE - Data destruction
• DELETE / UPDATE without WHERE clauses - Mass data corruption
• INSERT - Unauthorized data creation
• Schema modifications - Structural changes
• User/permission manipulation - Privilege escalation

Mitigation:

• Use read-only database users for analyst and developer roles
• Implement database-level permissions strictly
• Require approval workflow for destructive operations
• Enable audit logging for all query executions
• Regularly review executed queries
• Consider implementing query whitelisting for production databases

HIGH RISK: Database credentials are stored encrypted but:

• Anyone with access to the application database AND the encryption key can decrypt credentials
• The encryption key must be kept absolutely secure
• Loss of the encryption key means loss of all stored credentials

Mitigation:

• Store the ENCRYPTION_KEY in a secure vault (e.g., HashiCorp Vault, AWS Secrets Manager)
• Never commit the encryption key to version control
• Use different encryption keys for each environment
• Implement key rotation procedures
• Backup encryption keys securely
• Limit access to the application database

MEDIUM RISK: Scheduled queries run automatically without human oversight:

• Malicious scheduled queries can cause damage repeatedly
• Failed queries may go unnoticed
• Time-sensitive data operations may execute at wrong times

Mitigation:

• Implement mandatory approval for all scheduled queries
• Require peer review before activation
• Set up alerting for failed executions
• Implement schedule change audit trail
• Test schedules thoroughly in non-production environments
• Use timezone awareness correctly

MEDIUM RISK: Query results can be exported, potentially exposing sensitive data:

• Large datasets can be downloaded as CSV/Excel/JSON
• No built-in data loss prevention (DLP)
• Export actions are logged but not prevented

Mitigation:

• Implement export size limits
• Monitor export activity
• Restrict export permissions by role
• Implement data masking for sensitive fields
• Enable alerts for large exports
• Review export audit logs regularly

MEDIUM RISK: API endpoints are secured with JWT but:

• Stolen tokens can be used until expiry
• No built-in token revocation mechanism
• Rate limiting must be properly configured

Mitigation:

• Use short token expiry times (default: 7 days, consider reducing)
• Implement token refresh mechanism
• Enable rate limiting on all endpoints
• Monitor for unusual API activity
• Implement IP whitelisting where possible
• Use MFA for admin accounts (requires implementation)

1. No Built-in MFA: Multi-factor authentication is not currently implemented
2. No Query Timeout Protection: Long-running queries can impact system performance
3. Limited DLP: No built-in data loss prevention mechanisms
4. No Query Whitelisting: Cannot restrict to approved queries only
5. No Database Activity Monitoring: Relies on database-level auditing

1. Network Security

   • Deploy behind a VPN
   • Use firewall rules to restrict access
   • Implement IP whitelisting
   • Use private networking for database connections

2. Monitoring & Alerting

   • Set up SIEM integration
   • Enable real-time alerting for:
     • Failed login attempts (>5 in 10 minutes)
     • Destructive query execution (DROP, DELETE, UPDATE)
     • Large data exports (>10,000 rows)
     • Scheduled query failures
     • Permission changes

3. Access Control

   • Implement SSO/SAML if possible
   • Use strong password policies
   • Regularly audit user permissions
   • Disable inactive accounts
   • Implement session timeout

4. Database Protection

   • Use separate database users per application role
   • Never use database admin accounts
   • Enable database audit logging
   • Implement database-level query timeout
   • Use read replicas for analyst queries

5. Backup & Recovery

   • Regular automated backups
   • Test restore procedures
   • Document disaster recovery plan
   • Keep backups encrypted
   • Store backups in separate location

Pre-Production Deployment:

• Changed default admin password
• Generated strong JWT_SECRET (32+ characters, random)
• Generated secure ENCRYPTION_KEY (exactly 32 characters, random)
• Configured HTTPS/SSL with valid certificate
• Restricted database access (no admin accounts)
• Enabled database SSL/TLS connections
• Configured firewall rules
• Set up rate limiting (enabled and tested)
• Configured CORS properly (no '*' wildcards)
• Enabled audit logging
• Set up monitoring and alerting
• Tested backup and restore procedures
• Reviewed all user permissions
• Implemented network segmentation
• Documented security procedures
• Trained team on security practices
• Set up incident response plan
• Configured log retention policies
• Enabled Redis password authentication
• Reviewed all environment variables

Regular Security Maintenance (Monthly):

• Review access logs for anomalies
• Audit user permissions
• Update dependencies (npm audit)
• Review and rotate credentials
• Test disaster recovery
• Review executed queries
• Check for failed login attempts
• Verify backup integrity
• Update security documentation
• Review scheduled queries

If handling regulated data, ensure compliance with:

• GDPR: Right to erasure, data portability, consent management
• HIPAA: PHI protection, access controls, audit logging
• SOX: Financial data controls, audit trails
• PCI DSS: If storing/processing payment card data (NOT RECOMMENDED)

This application does not provide built-in compliance features. You are responsible for implementing additional controls as required by applicable regulations.

# DO NOT use these example values - generate your own!

# Strong JWT secret (generate with: openssl rand -base64 48)
JWT_SECRET=your-very-long-random-secret-at-least-32-characters

# Encryption key - EXACTLY 32 characters (generate with: openssl rand -base64 32 | cut -c1-32)
ENCRYPTION_KEY=abcdefgh12345678abcdefgh12345678

# Short token expiry for better security
JWT_EXPIRES_IN=24h

# Production mode
NODE_ENV=production

# Database with SSL
DATABASE_URL=postgresql://readonly_user:strong_pass@host:5432/db?sslmode=require

# Redis with password
REDIS_URL=redis://:redis_password@host:6379

# Query safety limits
QUERY_TIMEOUT_SECONDS=300
MAX_CONCURRENT_EXECUTIONS=5
MAX_EXPORT_ROWS=10000

If you suspect a security incident:

1. Immediate Actions:

   • Disable affected user accounts
   • Change compromised credentials
   • Review audit logs
   • Notify stakeholders

2. Investigation:

   • Identify scope of incident
   • Determine affected data/systems
   • Collect evidence
   • Document timeline

3. Remediation:

   • Fix identified vulnerabilities
   • Restore from backups if needed
   • Update security controls
   • Implement additional monitoring

4. Post-Incident:

   • Conduct retrospective
   • Update security procedures
   • Train team on lessons learned
   • Report to appropriate authorities if required

1. Query Execution Risk

   • Users with query execution permissions can run arbitrary SQL
   • Implement connection-level permissions carefully
   • Consider using read-only database connections for analysts
   • Audit query executions regularly

2. Scheduled Query Risk

   • Scheduled queries run automatically without human oversight
   • Review and approve scheduled queries before activation
   • Monitor execution logs for suspicious activity
   • Implement approval workflow for sensitive schedules

3. Export Functionality

   • Query results can be exported to CSV/Excel/JSON
   • Large result sets may impact performance
   • Implement export size limits
   • Monitor export activity for data exfiltration

Before deploying to production:

• Change default admin password
• Generate strong JWT_SECRET and ENCRYPTION_KEY
• Configure proper CORS settings
• Enable HTTPS/SSL
• Restrict database access
• Configure firewall rules
• Set up monitoring and alerting
• Enable rate limiting
• Review and limit user permissions
• Configure backup strategy
• Test disaster recovery procedures
• Document security procedures
• Train team on security best practices

We will announce security updates through:

• GitHub Security Advisories
• Release notes (CHANGELOG.md)
• Email notifications (if configured)

Subscribe to repository notifications to stay informed.

• OWASP Top 10
• Node.js Security Best Practices
• PostgreSQL Security
• JWT Security Best Practices

For security-related questions or concerns:

• Use GitHub Security Advisories (preferred)
• Contact the repository maintainer through GitHub

Thank you for helping keep SQLPulse and its users safe!