Access control in database security

A database is useful only if the right people and apps can read and write the right rows. Access control is how you decide that. Get it wrong and you get data leaks, silent corruption, or outages. Get it right and most attackers never reach the interesting tables.

For WordPress, that database holds users, posts, options, and often customer data. Plugin bugs and SQL injection still matter, but so does who is allowed to touch what once they are inside.

What database security has to protect

Most designs aim at three outcomes:

• Confidentiality: stop unauthorized disclosure
• Integrity: stop unauthorized or unwanted changes
• Availability: keep legitimate queries working when you need them

Policies answer basic questions: who can access which objects, under what conditions, and who can grant that access to someone else.

Privilege posture: closed vs open

Security policies often sit on a spectrum:

• Minimal privilege (closed): deny by default; grant only what a role needs. This is least privilege in practice.
• Maximal privilege (open): allow by default; restrict only what you blacklist. Easier to ship, harder to defend.

Closed systems take more setup. They fail safer when someone invents a new account or a forgotten app starts querying production.

Who administers the rules?

How grants are managed shapes risk:

• Ownership-based: the owner of an object decides who can use it. Flexible, common in relational databases, easy to sprawl.
• Hierarchical / decentralized: a top authorizer delegates subsets of rights to managers.
• Cooperative: a group must approve access to shared resources (useful for sensitive datasets, awkward for day-to-day ops).

Pick a model you can audit. An undocumented grant is a future incident report.

Control mechanisms beyond “can SELECT?”

Flow control

Flow control limits how data moves between objects: read from X, write to Y. Policies usually follow classification levels (what may flow up or down the ladder).

Inference control

Sometimes the danger is not a direct SELECT on a secret column. It is combining allowed answers to infer the secret. Classic cases:

• correlated visible fields that reveal a hidden one
• null responses that still signal existence
• statistical queries that narrow down individuals

Statistical databases often answer aggregates only. Defenses include data perturbation (noise or substitutes) and query control (limits on what a single query may touch). Query control is effective and expensive to administer well.

Access control models

Two classic families still show up in textbooks and product designs:

Discretionary access control (DAC)

The data owner decides. Grants are flexible. Central policy is weaker because each owner can create their own mess. Ownership-based admin is usually DAC.

Mandatory access control (MAC)

A global policy assigns security levels to subjects and objects. Flow between levels is enforced by the system, not by individual owners. Harder to bend for one app, stronger when classification matters (defense, regulated health data, and similar).

Object-oriented and composite models add inheritance, versions, and nested objects on top of subjects, objects, and rights. Relational systems still lean on matrices of (subject, object, permission). The right model depends on requirements analysis, not on a brand name.

Practical takeaways for WordPress operators

You rarely configure ORION-style models by hand. You do control:

• database users and host grants (app user ≠ root)
• least-privilege DB accounts for WordPress and tools
• who can run migrations, phpMyAdmin, or WP-CLI with DB access
• plugins that widen write access to options and user tables

Pair access control with app hardening: WordPress security checklist, role hygiene in WordPress user roles, and monitoring for odd admin activity via something like Events Logger.

Access control will not replace patches or backups. It shrinks what a stolen credential or buggy query can reach.