How a database is compromised (and how to prevent it)

Published on 2026-09-12 by frfrand

Los cinco caminos reales por los que se filtran datos, en orden de frecuencia. Ninguno implica romper el cifrado, y casi todos se cierran con decisiones que ya conocés.

When people talk about "hacking a database," the mental image is usually someone breaking encryption. In reality, almost no breach happens that way.

These are the real paths, in order of frequency.

1. It was open

The most common, and the least glamorous.

A database port exposed to the Internet, with a weak password or no authentication at all. Entire networks scan the address space looking for exactly that, all day long.

It was almost never opened on purpose: it was left that way after a test, a migration, or a "I'll open it for five minutes."

This is how it's closed: the database listens only on localhost, and remote access is via tunnel or private network. If something doesn't need to be open, it isn't opened.

2. SQL injection

Still relevant after twenty-five years.

It happens when user input is pasted into a query as text. If someone writes something that includes quotes and more SQL, that SQL gets executed.

The solution is not to manually escape quotes, nor to filter suspicious words. It is to use parameterized queries: the value travels apart from the query and never becomes part of the SQL.

# vulnerable q = "SELECT * FROM usuarios WHERE mail = '" + mail + "'"

# correct cur.execute("SELECT * FROM usuarios WHERE mail = %s", [mail])

Every modern ORM does this by default. The risk appears when someone builds a query manually "because the ORM didn't support it."

3. A leaked credential

The database password ended up in a commit, in a log, in a screenshot, in a chat.

This reduces to: credentials outside the code, .env ignored from the first commit, and —most importantly— rotate them as soon as you suspect anything. Remember that deleting a key from a commit does not remove it from history.

4. Too many privileges

This one doesn't open the door, but it decides how much is lost.

If your application connects with the administrator user, any of the three paths above gives total access: read everything, modify everything, delete everything.

If it connects with a user who can only read and write to the tables it uses, the same failure has a much smaller scope.

It is the cheapest measure of all and the one most often skipped, because at first "it's more convenient this way".

5. The backup

The database may be perfectly protected and the nightly dump may be in an accessible folder, or in a misconfigured cloud storage, or on someone's laptop.

A backup is a complete copy of your data without any of the database's protections. It deserves the same care: encryption, strict permissions, and limited access.

What to look at today

Five concrete questions:

• Does the database listen on all interfaces or only on localhost?
• Does your application connect with the superuser?
• Is there any query built with text concatenation?
• Where are the backups and who can read them?
• When was the engine last updated?

None of those questions requires advanced security knowledge. That's exactly the point: most breaches could be avoided with decisions the team already knew how to make.