What is Database Exposure?

Database exposure means a database engine is reachable from the internet on its network port. Databases are designed to be spoken to by applications on a trusted network, so exposure removes the assumption the security model rests on. Where authentication is absent or weak, the consequence is not a foothold to build on — it is direct access to the data.

Ports worth knowing

• 3306 — MySQL and MariaDB
• 5432 — PostgreSQL
• 1433 — Microsoft SQL Server
• 1521 — Oracle
• 27017 — MongoDB
• 6379 — Redis
• 9200 — Elasticsearch; see Elasticsearch exposure
• 5984 — CouchDB
• 11211 — Memcached

Port scanning finds these quickly, and service fingerprinting usually identifies the engine and version from its handshake even before any login is attempted.

How it happens

Rarely on purpose. A cloud security group opened for troubleshooting and never closed. A container published with a host port binding rather than an internal one. A default bind address of all interfaces on a server that later got a public IP. A managed database created with public access enabled because the application was elsewhere. Historically, several NoSQL engines shipped binding to all interfaces with no authentication by default — a pattern later versions corrected, but old instances persist.

What follows exposure

Unauthenticated engines can be read and written directly. Authenticated ones face password guessing and credential stuffing, and their version may carry a known CVE. An over-privileged database account then decides how much a successful login is worth, which is where least privilege earns its place.

The fix is usually configuration rather than code: bind to an internal interface, restrict source addresses, require authentication and TLS, and place the database behind network segmentation.

Related concepts

See attack surface reduction, security misconfiguration and default credentials. For data-protection duties around exposed personal data, see GDPR Article 32.