When a data breach makes headlines, the root cause often traces back to something depressingly simple. Not a sophisticated zero-day exploit. Not a nation-state attack. Just a database that allowed too many people to access too much data with too few restrictions.
Broken access controls sit at the top of the OWASP Top 10 for good reason. Organisations grant database access liberally during development, intending to tighten permissions before going live. That tightening rarely happens. The development permissions become the production permissions, and sensitive data sits exposed to anyone with a network connection and valid credentials.
How Access Control Failures Escalate
A customer service representative who can query the entire customer database rather than just their assigned accounts represents a failure of least privilege. A web application that connects to the database with a service account holding full read-write permissions across all tables creates a single point of catastrophic failure.
When attackers compromise any account or application with excessive database privileges, they access everything that account can reach. The blast radius depends entirely on how tightly those privileges were scoped.
William Fieldhouse, Director of Aardwolf Security Ltd, comments: “In nearly every internal assessment, we discover databases accessible from far more network segments than necessary. Combine that with shared service accounts using weak passwords, and you have a recipe for total data compromise. Restricting database access to specific application servers and enforcing individual authentication would eliminate the majority of these findings.”
Testing and Hardening
Regular internal network penetration testing reveals whether databases are reachable from network segments that should never access them. Testers attempt to connect from compromised workstations, VPN pools, and guest networks to map actual database exposure rather than relying on documented network diagrams that may not reflect reality.
Complement manual testing with vulnerability scanning services that check database instances for default credentials, missing patches, and insecure configurations on a continuous basis. Databases frequently drift from their hardened baseline after software updates or emergency changes.
Fixing the Fundamentals
Implement row-level security where supported. Use stored procedures to abstract direct table access. Audit database queries and flag unusual volumes or patterns. Encrypt data at rest and in transit.
The problem extends to backup databases and reporting replicas. Organisations frequently protect their primary production database but grant wider access to read replicas used for reporting. Those replicas contain the same sensitive data with fewer access restrictions, and attackers know to look for them.
Consider implementing database activity monitoring that tracks every query against sensitive tables and alerts on unusual patterns. A sudden export of the entire customer table at three in the morning on a Saturday should trigger an immediate investigation regardless of whether the requesting account has technical permission to run that query.
Database security is not glamorous work. There are no exciting tools or flashy dashboards. It is careful, methodical hardening that prevents the kind of breaches that destroy customer trust overnight. Get the access controls right and everything else becomes significantly harder for an attacker to exploit.
