WordPress
wp-config.php
wp-config.php is the WordPress configuration file that holds the database credentials, the security keys and salts, the table prefix, and many behavior constants. Core reads it before anything else.
How it is measured
The required entries are DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, and the eight keys and salts such as AUTH_KEY and LOGGED_IN_SALT. Optional constants include WP_DEBUG, WP_MEMORY_LIMIT, DISABLE_WP_CRON, WP_POST_REVISIONS, and DISALLOW_FILE_EDIT. The file may sit in the site root or one directory above it.
Audit it by reading it, and with ls -l wp-config.php to check permissions, ideally 640 or 600. wp config list shows every defined constant from the shell, and wp config shuffle-salts regenerates the keys.
Worked example
A site on shared hosting is cloned for a client. The developer forgets to change the salts, so both sites use the same eight keys. A login cookie from one is valid on the other, since they share the same user table dump.
Running wp config shuffle-salts on the clone invalidates every existing session there. The other site is unaffected.
How it differs
wp-config.php is the file, and the table prefix is one setting inside it. The file differs from the wp_options table, which holds settings editable in wp-admin. Values in wp-config.php cannot be changed from the dashboard and take priority over database options for constants such as WP_HOME and WP_SITEURL.
Common errors
Committing it with live credentials to a public repository. Setting 666 permissions. Adding code after the line that says stop editing, so constants are defined too late. Leaving WP_DEBUG_DISPLAY on in production. Using the same salts on every environment.
In practice
Check permissions on the file today. Move secrets to environment variables if your host supports them, and keep a wp-config-sample in version control. Rotate the salts after any suspected compromise.