Database integrity

The database is not just your data

Most of the checks in this group are about limiting what a single compromise can reach, not about protecting content from being lost. A default table prefix (jos_ or wp_) is not a secret, it is a convenience for anyone writing a generic SQL-injection payload that assumes it and gets to skip the step of finding out. A database user with root privileges, or one scoped across every database on the server rather than just the one it needs, turns “this site’s database got compromised” into “every site sharing that server’s database got compromised”, which on shared or reseller hosting is a realistic blast radius rather than a theoretical one. How to check Joomla database security walks through the full picture, including the questions this group’s automated checks do not ask on their own.

The rest of the group is about drift between what the CMS expects and what is actually sitting in the tables: a schema that is behind the version the CMS thinks it is running, backup tables an old migration or a nervous developer left behind and never dropped, pending migrations that never completed. None of these are attacks. They are the database equivalent of the configuration drift elsewhere in this reference, quiet enough that nothing breaks obviously, until an update assumes a column exists that a stalled migration never added.

On a portfolio of sites built up over years by different people, database hygiene is one of the places where the gap between “was fine at launch” and “still fine now” opens widest, because nobody looks at table structure unless something visibly breaks. A user action log nobody purges, growing without limit, is the same story: harmless until the table is large enough to slow every query that touches it. None of this needs a file-by-file scan to detect, which is why every check in this group runs on the twice-daily snapshot rather than waiting on a longer audit cycle.