azionelab-v2/docs/security.md

Security

• NGINX is the only published service. MariaDB is restricted to an internal network; WordPress is reachable only from NGINX and the database network.
• Production startup rejects placeholder or short database passwords. .env is ignored and real secrets must come from the deployment secret manager.
• WordPress uses its normal capability, nonce, authentication, cookie, and password controls. Theme settings sanitize input and templates escape output.
• Structured Shows and Gallery content is editable in WordPress admin but is consumed by the homepage only; it is not exposed as standalone public routes or REST collections.
• File editing is always disabled. Production also disables web-based core, theme, and plugin changes; patched images are rebuilt and redeployed instead.
• XML-RPC and comments are disabled. NGINX blocks PHP execution below uploads, dotfiles, and direct wp-config.php requests, and rate-limits login/public requests. Apache also denies uploaded PHP files and direct access to sensitive WordPress internals as defense in depth. Public REST user enumeration and author archives are disabled.
• Security headers include CSP, same-origin framing, content-type protection, a strict referrer policy, and a restrictive Permissions Policy. WordPress compatibility still requires inline style/script CSP allowances; do not treat this CSP as an XSS sanitizer.
• Forwarded client/protocol headers are overwritten by default. Trust mode is permitted only behind a restricted load balancer that overwrites those headers.
• Direct TLS is fail-closed until a certificate exists. Certbot has a read-only root, no Docker socket, dropped capabilities, and narrowly scoped volumes.
• Containers are not privileged and do not use host networking or the Docker socket. WordPress/Apache retains the capabilities needed by the official image internally, but no WordPress port is published. A containerized security test fails if the WordPress service is configured with host-published ports.
• Persistent state uses host-based bind mounts. Keep those paths outside the public web root, restrict host access, never make them world-writable, and run ./scripts/prepare-host-volumes.sh when paths or image user IDs change.
• WordPress/Apache access logs are disabled to avoid duplicate client metadata and healthcheck noise; NGINX remains the single request log and PHP warnings/errors stay visible.
• Admin MFA, an IP/VPN allowlist, SMTP, malware scanning, log aggregation, and a secret manager remain production operator responsibilities.
• Backups and uploads can contain personal data. Encrypt, restrict, retain, and delete them according to the applicable privacy policy.

See ADR-0001.