Database Security

Database security is mostly about assuming something upstream will eventually be compromised, and limiting what that reaches.

Encryption, and what each kind actually protects. In transit (TLS) protects against network interception. At rest protects against someone obtaining the disk or a backup file — it does nothing against an attacker with valid database credentials, because the database decrypts for them exactly as it does for you. Application-level or column-level encryption is the one that limits a compromised database: the ciphertext is useless without a key the database does not hold. Reserve it for genuinely sensitive fields, because you cannot index or search encrypted columns normally.

Least privilege is the highest-value control. Your application should not connect as a superuser. A read-only user for analytics, a migration user that is the only one able to alter schema, and an application user that can read and write rows but not drop tables — that structure means a SQL injection in a reporting endpoint cannot destroy anything.

Row-level security pushes authorisation into the database, so a policy decides which rows a session may see. It is particularly valuable in multi-tenant systems, because tenant isolation stops depending on every query remembering its WHERE tenant_id clause. Forgetting that clause once is a cross-tenant data leak.

Audit logging answers who read or changed what. It is a detection and compliance control rather than a preventive one, and it is only useful if the logs go somewhere the database user cannot edit.

Backups are part of your attack surface. They contain everything the database does, are frequently stored with weaker controls, and are the copy that gets left on someone's laptop. Encrypt them, restrict access, and — the part everyone skips — test the restore, because an untested backup is a hope rather than a control.