Database Security Fundamentals

Build the mental model

Database security is not one setting to turn on; it is a stack of independent layers, and a weakness in any single layer can undo the rest.

Authentication answers 'who are you' — password, certificate, cloud IAM role, or token. Authorization is the separate, equally necessary layer that decides what that identity may actually do.

Network access is the next layer: a production database should never be reachable from the open internet. It belongs on a private network, behind a firewall that allows only known application servers.

DATABASE SECURITY LAYER STACK
-----------------------------
  +---------------------------------------+
  | Monitoring (detect unusual activity)   |
  +---------------------------------------+
  | Backups (recover from disaster)        |
  +---------------------------------------+
  | Secrets (credentials never in git)     |
  +---------------------------------------+
  | TLS (encrypt data in transit)          |
  +---------------------------------------+
  | Network Access (private, firewalled)   |
  +---------------------------------------+
  | Least Privilege (minimum permissions)  |
  +---------------------------------------+
  | Authorization (what can this do?)      |
  +---------------------------------------+
  | Authentication (who is connecting?)    |
  +---------------------------------------+
        A gap in any single layer weakens
        every layer stacked above it.

Connect it to a real scenario

Applying this to a real deployment means auditing every account that can reach the database — the application's runtime connection, any analytics tool, any admin, and any CI/CD job that runs migrations.

Most teams find at least one account with far more access than it uses. Fixing this needs no deep expertise — just the discipline of re-asking whether an account still needs a permission, on a schedule.

• For hands-on permission commands: PostgreSQL's roles-privileges-and-row-security and connections-pooling-and-security lessons.
• For hands-on ACL and TLS configuration: Redis's security-acl-tls lesson.

• Database security is layered — authentication, authorization, least privilege, network access, and TLS each guard against a different failure.
• Least privilege means every account, including the application's own connection, gets only the permissions its actual job requires.
• TLS encrypts data in transit but does nothing for an exposed database protected only by a shared superuser password.

Database Security Fundamentals

• Authentication is required for every connection — no anonymous access.
• Each account has only the permissions its actual job requires (least privilege).
• No application or service runs as superuser or root.
• The production database is not unnecessarily exposed to the public internet.
• TLS is used to encrypt connections to the database.
• Credentials are never committed to Git or stored in plain text in code.

Try the working example

function checkLeastPrivilege(accountName, granted, needed) {
  const excess = granted.filter((perm) => !needed.includes(perm));
  return {
    account: accountName,
    grantedCount: granted.length,
    neededCount: needed.length,
    excessPermissions: excess,
    isOverPrivileged: excess.length > 0
  };
}

const appAccount = checkLeastPrivilege(
  "app_service",
  ["SELECT", "INSERT", "UPDATE", "DELETE", "DROP TABLE", "CREATE ROLE"],
  ["SELECT", "INSERT", "UPDATE"]
);

const analyticsAccount = checkLeastPrivilege(
  "analytics_readonly",
  ["SELECT"],
  ["SELECT"]
);

console.log(JSON.stringify(appAccount, null, 2));
console.log(JSON.stringify(analyticsAccount, null, 2));

For app_service (granted SELECT, INSERT, UPDATE, DELETE, DROP TABLE, CREATE ROLE but only needing SELECT, INSERT, UPDATE), the checker reports excessPermissions: ["DELETE", "DROP TABLE", "CREATE ROLE"] and isOverPrivileged: true. For analytics_readonly (granted and needing only SELECT), it reports an empty excessPermissions array and isOverPrivileged: false — exactly the properly-scoped case.

OWASP: Database Security Cheat Sheet — How Databases Work