A database penetration test is rarely a separate engagement you book on its own. In practice, the database is tested as part of a web application or network penetration test, which reaches the data behind your app, but only in part. Your database holds the records that matter most: customers, payments, sometimes health data, so it is worth knowing how much of it those tests actually cover, how serious a single database flaw can be, and when to have the testers go deeper. This article is written for the person who owns the data, not the person who runs the database.
Quick Answers
What is a database penetration test?
It is the part of a security test that targets the data layer: the database, its user accounts and privileges, its configuration, whether the data is encrypted, and how reachable it is across your network. It is seldom booked on its own. Most often it happens inside a web application or network penetration test, which already reaches the database to some degree.
Is my database tested in a web app or network pentest?
Yes, but only in part. A web app test reaches the database through the app’s own queries, so it catches injection and some access-control flaws. A network test finds the database on your network and checks its ports, its version, and whether it accepts weak or default logins.
When is that partial coverage not enough?
When the data is sensitive or regulated (payment data, health records, personal data at scale), when one database sits behind several apps or customers, or when it was set up years ago and never hardened. In those cases it is worth having the testers go deeper on the database inside the engagement.
Your Database Is the Target, and the Least-Tested Layer
The database holds your most valuable data, which makes it the thing attackers are working toward and, oddly, the layer that gets the least direct testing. It is rarely left out entirely, since a web app or network pentest already reaches the database in passing. What it rarely gets is attention on its own terms, and that gap is where the risky assumptions live. Three of them explain the gap:
- “It is behind the firewall, so it is safe.” Most breaches start from inside the perimeter: a stolen password, injection through the app, a compromised laptop, or an insider. Once an attacker has any foothold, a database that trusts anything labeled “internal” is the softest target in the building.
- “The cloud provider handles it.” With a managed database, the provider secures the hardware; you still own the accounts, privileges, and encryption settings, which is exactly where the findings come from.
- “The app pentest covered it.” Common enough that it gets its own section below.
Each time, the data most worth stealing is assumed to be someone else’s responsibility. Testing the data layer directly removes that assumption and puts the work where the real risk is.
What a Database Pentest Actually Checks
The clearest way to read the findings is to follow the path an attacker takes once they are near your data, not a flat checklist. Each weakness below comes with the damage it does.
Injection. The classic database attack: malicious input fed through the app so the database runs the attacker’s own commands (SQL injection). One flaw can hand over entire tables of customer records, let someone log in as another user, or run commands on the server itself. It slipped a couple of places in the latest OWASP Top 10, the industry’s reference list of top web risks, but it is still one of the most common ways data leaks.
Too much access. Accounts often carry far more power than the job needs, the opposite of “least privilege,” where each account gets only the rights it must have. A service account running as near-administrator, or one customer’s records reachable from another’s login, lets a small foothold read or change data it should never touch.
Escalation to admin. The test checks whether a limited account can quietly climb to full control. Through a single configuration mistake, a user who should only see their own data can turn into the database administrator, the account that runs everything.
Weak or default passwords. Factory logins left unchanged, shared across staff, or with no lockout after repeated failures. A guessing attack then walks straight in.
Unencrypted data. The test checks whether data is encrypted “at rest,” scrambled on disk so a copy is useless without the key. When it is not, a single stolen backup or disk snapshot is a full breach on its own.
Outdated software and over-exposure. An unpatched database carries publicly known flaws a ready-made exploit can trigger. One reachable from the public internet, or from too much of your own network, is a scan away from being found. The test confirms who can connect, and from where.
It ends by checking how far one compromised database lets an attacker go: passwords reused elsewhere, links to other servers, a route deeper into your systems. One database can become the whole environment.
The Databases You Run, and What an Attacker Gets
How bad a flaw turns out to be depends on which database sits behind your app, and it is usually worse than people expect. Pulling a copy of every record, a data dump, is the obvious harm, and on its own it is serious: a full customer or payment table in the wrong hands is a reportable breach. But on most engines a single injection does not stop at reading data. Under the right conditions it becomes remote code execution (RCE), where the attacker runs their own commands on the server and can take the whole machine. Here is how that tends to play out on the databases most companies run.
- MySQL and MariaDB, behind a large share of web apps: an injection can copy tables, and where the database account is allowed to write files, it can drop a small program into the website’s own folder and run it, turning a data leak into control of the server.
- PostgreSQL, common in modern and cloud apps: beyond reading data, a powerful database account can use a built-in feature to run operating-system commands directly, so one flaw becomes a foothold on the host.
- Microsoft SQL Server, common in Windows and enterprise shops: it includes a command-running feature that, once enabled and reachable by a privileged account, takes an injection straight from reading data to running commands on the server, and from there to other machines.
- Oracle, found in large enterprises and finance: packed with built-in packages a determined attacker can chain to read files, reach the network, and in some setups run code, on top of the usual data exposure.
- MongoDB, the common NoSQL choice (it stores flexible documents rather than tables): the classic flaw is an authentication bypass, where crafted input tells the database to match any account and skip the password. Many MongoDB servers have also been left on the internet with no password at all, which is behind several of the largest open-database leaks.
The pattern is consistent. The database is rarely the last step: what begins as one unchecked input becomes a copy of your data, then often the server it runs on, then whatever that server can reach.
How Much a Web App or Network Pentest Already Covers
Quite a lot, which is where the confusion starts. A web application pentest reaches the database through the app’s input fields: when the tester probes for injection, those requests run against the database behind the app, so injection and some access-control flaws surface. A network or infrastructure pentest comes at it from the other side, finding the database on the network and checking its exposed ports, its version, and whether it accepts weak or default logins. Between them, a good slice of the data layer is already exercised.
What neither does on its own is examine the database on its own terms. Working through the app, or scanning from the network, the testers see only what is exposed to them. They are not logged into the database itself, so its internal accounts and privileges, whether a low-privilege login can climb to full control, whether stored data is encrypted, and who else can reach it go unchecked. A test can come back clean while all of that sits unexamined behind it.
Going deeper means logging into the database with a real account and working it head-on, the way an attacker already inside the network would. A standard engagement does some of this; a larger one does much more, because there is time to examine the data layer rather than only the app or network in front of it.
When Your Database Belongs in the Test Scope
You do not buy a database pentest on its own. The real decision is whether to name the database in the scope of your next engagement, so the tester digs into it rather than only brushing past it.
A few situations make that worth doing: you hold regulated or high-value data (payment details, health records, personal data at scale); one database sits behind several apps, services, or customers, so one weakness exposes all of them; or the database predates your current team, was never hardened, or was recently migrated or moved to the cloud, where stale accounts and new exposure tend to collect.
For a small single-app database with little sensitive data, the coverage folded into a thorough app or network test may be enough, though it is still worth confirming it was named in the scope. When the database should be tested in full, the step is to ask for it while scoping the engagement.
What Compliance Actually Wants From Your Database
Most data-protection rules converge on two things, and both are properties of the database: that stored data is encrypted, and that access to it is controlled. A general app or network test touches the access side only partially, nowhere near in full, and it does not look at encryption at rest at all. That is why the database is where this evidence is produced.
PCI DSS, the standard for handling card payments, is the clearest fit. It requires stored cardholder data to be made unreadable, usually by encryption (Requirement 3), a penetration test run on a documented methodology at least once a year (Requirement 11.4), and least-privilege access with strong authentication on the accounts that can reach that data (Requirements 7 and 8). A database test is where each of those is checked against reality instead of a policy document.
HIPAA, which governs health data, requires periodic technical evaluations of security. A rule proposed in January 2025 would go further, turning encryption from today’s flexible option into a firm requirement and making annual penetration testing explicit, though that rule is still proposed and not yet in force. GDPR points the same way for personal data: its Article 32 names encryption and regular security testing as expected measures.
SOC 2 and ISO 27001 do not call for a specific database test. What auditors look for is evidence that the systems holding data were tested credibly and the findings fixed. Because encryption and access control live inside the database, testing the database itself is what turns that expectation into something you can show.
How CYBRI Tests Your Database
At CYBRI, basic database coverage comes with every engagement. Testing an app, API, network, or cloud environment runs straight through the data behind it, so the database is already reached to some degree in every program, at no extra step on your part.
If you handle sensitive data and want the full picture, that coverage can be taken further: a complete database pentest from the inside, where a tester works from a low-privilege or unprivileged account and tries to escalate, read data they should not, and move outward, the way an attacker who already has a foothold would. It is not sold on its own, but it slots straight into the engagement when you add it to the scope.
Whichever depth you choose, the work is run the same way:
- Senior, OSCP-certified testers with a manual-first approach, so the findings that matter are the ones a real attacker would reach.
- A scoping step that sets up access, usually a low-privilege account and connection details, so the database is examined from the inside rather than from the outside in.
- A report written for two readers: a short summary for the people approving the work, and the technical detail, with fix steps, for the people who will act on it. Every finding is scored for severity.
- About three months of remediation support and retesting afterward, so fixes are confirmed rather than assumed.
- Findings mapped to your framework, whether that is PCI DSS, HIPAA, SOC 2, ISO 27001, or GDPR.
If you handle sensitive data and want the database tested in full, contact CYBRI and it can be added to your scope.
Frequently Asked Questions
Isn’t my database safe because it is internal, behind the firewall?
No. Most database breaches start from inside the perimeter, through a stolen password, injection in the app, a compromised laptop, or an insider. Once an attacker has any foothold on the network, the firewall is already behind them, and a database that trusts anything labeled “internal” is an easy target.
Does my cloud provider secure my managed database?
Only part of it. The provider secures the hardware and the service it runs on. You still own the accounts, the privileges, the encryption settings, and the database’s exposure, and that is where most findings come from.
Do I have to give the tester access to the database?
Normally yes, usually a low-privilege account and connection details. That is not making the test easier. It points the test at the data, the way a real attacker who already has a foothold would work, so the time is spent on real findings instead of trying to get in.
Does PCI, HIPAA, or GDPR require a database test specifically?
No framework names a “database test.” They require stored data to be protected and access to it controlled, which is exactly what a database test checks. PCI DSS also expects a penetration test run on a documented methodology at least once a year.
Is database testing a separate purchase, and what does it cost?
No. Basic database coverage is already part of every engagement, and the deeper, internal database pentest is added to the scope when you want it, so it is never a line item you buy on its own. CYBRI’s larger plans that include that depth start at $9,500, and the cost tracks the overall scope rather than a per-database charge. Run it at least once a year and after any significant change, such as a migration or a new type of data.
If your database holds data worth protecting, talk to CYBRI and make sure it is named in the scope of your next penetration test.
