Security layer

title: The security layer description: Security measures added during 1.x: upload-directory hardening, CSRF, two-factor authentication, the recovery console, digest-verified patches and encrypted secrets.

Upload-directory hardening. A five-layer .htaccess for public/uploads: access denial, handler removal, engine off, CGI off and a restrictive CSP.
CSRF protection, captcha and flood limiting.
Two-factor authentication.
Audit log and security centre.
A recovery console that stays reachable when the database or firewall fails (AACP_RECOVERY_TOKEN).

File-level patches (see Patches and interrupted updates) come with these rules:

Patch bodies are fetched only from CPalius-owned addresses, and every file is SHA-256 verified before it is written. If one does not match, not a single byte reaches the project tree; a half-applied patch is a mixture of versions nobody has ever tested.
A patch cannot write to cp-includes/vendor, public/uploads, cp-core/var or .env. The rule lives in one place shared with the full updater; a rule kept in two copies eventually diverges, and the diverging side becomes a hole.
A patch must ship CpVersion.php, and the downloaded file's constant must state the manifest's version. Without this, a manifest announcing 1.1.1 while shipping 1.1.0 code would apply, leave the running version where it was and be offered again on every check.
No patch is ever applied on its own. There is no code path from the cron check to the installer; a CSRF-protected form or a deliberate command is required.
Storage credentials are stored encrypted (SettingSecretCodec in cp_settings). The screen never renders a secret back; an empty password field means "leave the stored value alone".

Changing an e-mail address or username now waits for an administrator. See Mail templates and account changes.

A change that needs a new dependency cannot ship as a patch (a patch cannot write into cp-includes/vendor); it needs a full release.