Skip to content

Database exposed to internet

What has been found

Database exposed to internet.

A database was found exposed to the internet.

Why this is a potential risk

Databases are designed to store sensitive and business-critical information such as customer records, financial data, or intellectual property. Exposing them directly to the internet introduces significant risk:

  • Credential Stuffing & Brute Force Attacks – Internet-facing databases are frequently targeted with automated scans and credential attacks.

  • Exploitation of Known Vulnerabilities – Attackers routinely exploit unpatched database flaws (e.g., MongoDB ransomware campaigns, MySQL/MSSQL exploits).

  • Data Exfiltration & Breach – Direct access could enable large-scale extraction of sensitive or regulated data (e.g., PII, PCI, PHI), triggering compliance and reputational impact.

  • Ransomware & Destructive Attacks – Numerous campaigns have deleted or encrypted publicly exposed databases and demanded ransom payments.

  • Pivot for Lateral Movement – An attacker who compromises a database service may escalate privileges and gain a foothold in the internal network.

  • Regulatory Consequences – GDPR, HIPAA, PCI-DSS, and other standards require safeguarding sensitive data. Internet-exposed databases typically represent a compliance violation.

Exposing databases to the internet drastically increases the likelihood of compromise, data theft, and regulatory penalties.

Potential solutions/Improvements

Architectural Controls

  • Remove direct internet exposure: Databases should never be directly accessible from the internet.

  • Restrict access to internal interfaces only (private subnets, VPCs, VPNs, bastion hosts).

  • Where external access is required, enforce IP allowlists, host-based restrictions, or private peering (e.g., AWS PrivateLink, Azure Private Endpoint).

Authentication & Access Management

  • Enforce strong authentication (long, unique passwords, preferably combined with IAM-based authentication).

  • Apply the principle of least privilege to database accounts and roles.

  • Remove unused/default accounts and disable anonymous or guest access.

Encryption & Configuration

  • Enable TLS/SSL encryption for data in transit.

  • Enable encryption at rest using native database encryption features or CSP-managed keys.

  • Disable or limit remote administrative access; prefer management via secured internal admin networks.

  • Apply vendor security hardening guides (e.g., CIS Benchmarks for MySQL, PostgreSQL, MongoDB, MSSQL).

Monitoring & Detection

  • Enable detailed logging (queries, failed logins, privilege changes).

  • Feed logs into a SIEM for anomaly detection and alerting.

  • Continuously monitor for unexpected external connections.

How to verify it is resolved:

  • Perform external vulnerability scans to confirm the database service is no longer exposed.

  • Review firewall/security group rules and ensure access is limited only to known and trusted networks.

  • Validate that authentication, encryption, and role-based access controls are enforced.

  • Run periodic penetration tests against the environment to confirm security posture.

  • Continuously check databases against known exploited vulnerabilities (CISA KEV catalog).

External references