Missing SSL/TLS Configuration in Sequelize Options
Node.js applications using Sequelize ORM connect to databases without explicit SSL/TLS configuration. By default, Sequelize constructors like new Sequelize(database, username, password, { host, dialect }) do not enforce encrypted connections unless explicitly configured through dialectOptions.ssl. When developers initialize Sequelize with basic options containing only host, port, and dialect properties, the ORM establishes unencrypted TCP connections to database servers. All database queries, authentication credentials, and result sets containing sensitive data (user records, financial transactions, personal information) transmit in plaintext across network infrastructure. Attackers positioned on the network path between application servers and database servers can passively capture network traffic using tools like tcpdump or Wireshark to extract SQL queries revealing schema information, authentication tokens in WHERE clauses, and complete record sets in SELECT results.
Using Default Database Connection Settings Without Encryption
Development teams adopt default Sequelize configuration examples from documentation or tutorials that prioritize simplicity over security, omitting SSL/TLS settings entirely. Popular Sequelize getting-started guides often demonstrate basic connection patterns like sequelize = new Sequelize('database', 'user', 'password', { host: 'localhost', dialect: 'postgres' }) without including dialectOptions: { ssl: { require: true, rejectUnauthorized: true } }. These minimal configurations work correctly for local development environments where database and application run on the same machine or trusted network, but the same code gets deployed to production where application servers connect to managed database services (AWS RDS, Google Cloud SQL, Azure Database) over network infrastructure. Without explicit SSL enforcement, production database connections transmit cleartext traffic exposing credentials during authentication handshake and data during query execution. Database connection strings in environment variables containing passwords remain vulnerable during the initial connection establishment phase.
Disabling SSL Verification for Development that Carries to Production
Developers configure dialectOptions: { ssl: { rejectUnauthorized: false } } to bypass certificate validation errors when connecting to local development databases with self-signed certificates or invalid certificate chains. During local development, PostgreSQL or MySQL instances often use self-signed certificates that fail standard certificate validation, causing Sequelize connections to throw UNABLE_TO_VERIFY_LEAF_SIGNATURE or DEPTH_ZERO_SELF_SIGNED_CERT errors. Rather than properly configuring trusted CA certificates for development environments, developers set rejectUnauthorized: false to disable certificate validation entirely, allowing connections to proceed regardless of certificate validity. This configuration setting gets committed to version control in config/database.js or similar files, then deployed to production environments where it disables protection against man-in-the-middle attacks. Attackers can present fraudulent certificates to intercept encrypted database connections because the application accepts any certificate without validation, defeating the purpose of TLS encryption.
Improper Certificate Validation Configuration
Sequelize SSL configurations use incomplete security settings that establish encrypted connections without proper certificate validation. Developers configure dialectOptions: { ssl: true } using boolean shorthand instead of comprehensive SSL objects, or set ssl: { require: true } without including rejectUnauthorized: true to verify certificate chains. These partial configurations establish TLS-encrypted connections but skip critical validation steps: verifying the server's certificate is signed by a trusted Certificate Authority, checking the certificate hasn't expired, confirming the certificate's Common Name matches the database hostname, and validating the complete certificate chain to a trusted root CA. Without proper validation, applications are vulnerable to man-in-the-middle attacks where adversaries present self-signed certificates or certificates issued for different domains, intercepting and decrypting database traffic despite the TLS connection appearing secure. Missing CA certificate configuration (ssl.ca property) prevents validation against internal/private Certificate Authorities used in enterprise environments.
Missing dialectOptions for SSL Enforcement
Applications fail to include the dialectOptions property required for database-specific SSL configuration in Sequelize connection options. Different database dialects (postgres, mysql, mariadb, mssql, sqlite) implement SSL/TLS through database-specific connection libraries (pg for PostgreSQL, mysql2 for MySQL, tedious for MSSQL) that each require different SSL configuration structures passed through Sequelize's dialectOptions property. Developers configure top-level Sequelize options like host, port, database, username, password but omit the nested dialectOptions: { ssl: {...} } structure required to pass SSL settings to the underlying database driver. For PostgreSQL connections using the pg library, SSL settings must be provided as dialectOptions: { ssl: { require: true, rejectUnauthorized: true, ca, cert, key } }. MySQL connections require dialectOptions: { ssl: { require: true, rejectUnauthorized: true } } or dialectOptions: { ssl: 'Amazon RDS' } for AWS RDS certificate bundles. Without dialectOptions, SSL configuration provided at other levels in the options object gets ignored by the database driver, resulting in unencrypted connections.