Security review checklist
This checklist is for the host's security reviewer or system administrator. Use it before a site goes live, after a security incident, and at least once a quarter. The reasons behind each item are on Security hardening and in chapter 13 of the installation book; the hosting view is on Hardening for hosts.
Warning
.htaccess slows down every request. When .htaccess files are enabled (AllowOverride anything but None), let alone
used, Apache looks for them and reads and evaluates them on every request, in every directory of the path, and
page loading times go up drastically (measured). The only real fix is to switch the feature off for
the virtual host: AllowOverride None in the HTTPS virtual host, and the rules in the virtual host's own
configuration as mod_rewrite rules. That is far faster in production speed tests and well worth the time it takes
to optimize a production configuration. Switch over right away: copy the rules of the
example HTTPS virtual host into your virtual host (with the static cache, also
staticcache_offload.conf), set AllowOverride None, run apachectl configtest, reload Apache and
test the site. The same rules for other servers: nginx, LiteSpeed,
Caddy, IIS, Velocity (built in); where virtual host rules go in a control
panel: Plesk, cPanel, DirectAdmin, ISPConfig.
On LiteSpeed or OpenLiteSpeed, the server's own page cache can also answer anonymous visitors and crawlers without PHP: Page caching with LiteSpeed and OpenLiteSpeed.
Site: <domain> Reviewer: <name> Date: <date> Reason: <go-live | incident | quarterly>Versions
- To do: Exponential is on the newest 6.0.x release, or the gap is documented with a date to close it. Only the 6.0 line
gets security fixes (
SECURITY.md). - To do: Extensions are on current releases.
- To do: PHP and the operating system receive security updates.
Accounts
- To do: No default or shared administrator password (The default administrator password).
- To do: Administrators use two-factor sign-in, where the customer agreed (Two-factor sign-in).
- To do: Every account with administration rights belongs to a named person who still needs it.
- To do: Anonymous has no policies beyond what the public site needs.
Settings and served files
- To do: Debug output is off on public siteaccesses.
- To do: Only the asset paths are served as files;
settings/,var/log,var/cacheand source files are not reachable from the web. Test it: a request for a file undersettings/must not return it. - To do: The setup wizard stays closed:
settings/override/site.ini.append.phphas[SiteAccessSettings] CheckValidity=false(Chapter 13, First sign-in and default passwords). - To do: Uploads are stored under
var/and are not executed as PHP.
Transport and headers
- To do: HTTPS everywhere, certificate valid, HTTP redirects (TLS and HTTPS).
- To do: The Content Security Policy is enforced in the administration and produces no unexpected reports (Content Security Policy).
- To do: The administration is restricted by network or a second factor, as agreed (Restricting the administration).
Logs and detection
- To do:
security.logis written and reviewed (Security log). - To do: Behind a proxy or load balancer,
TrustedProxies[]is configured so the logs see real client addresses (Security hardening). - To do: A shield in front of the site is decided: request-shield or the kernel's request rules (request-shield and request rules).
- To do: The audit trail is on and readable by the reviewer (Audit trail).
Isolation and secrets
- To do: The site runs as its own system user, with its own PHP-FPM pool or Velocity instance (Multi-tenant isolation).
- To do:
settings/overrideand backups that contain it are readable only by the site's user and the backup system. - To do: No secrets in Git repositories, tickets or shared folders.
- To do: The database user of the site can reach only the site's database.
Backups and recovery
- To do: Backups are stored off the machine and cannot be deleted from the site's account.
- To do: A restore was tested within the agreed period (Restore and restore tests).
Disclosure
- To do: Your team knows how to report a vulnerability in Exponential privately, as
SECURITY.mddescribes (Security updates and disclosure). - To do: Your own incident procedure is current (Compromised site).
Demo mode.
- To do:
grep -r EXP_DEMO_MODEover the PHP-FPM pools, virtual hosts,.htaccessfiles, systemd units and drop-ins, crontabs,/etc/environmentand container definitions finds only the configuration of public demos; no production site has ademo/modeline insecurity.logor asystem.demo.modeaudit event (Demo mode for hosts).
Related pages
- Security review summary for leaders
- Monthly operations checklist
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.