Security checklist #

This page is for developers who build sites and must hand them over secure. Exponential is secure by default in many places, and a project can still undo that with one careless role, template or setting. Go through these lists during development and again before launch; the hardening guide explains the attacks behind each item (Security hardening).

Contents #

1. Content model and access
2. Templates and output
3. Forms and uploads
4. Your own code
5. APIs
6. Configuration and deployment
7. Accounts
8. Go-live hardening
9. Watching and reporting

Content model and access #

• To do: The Anonymous role reads only what visitors may read (content/read on the public sections), and nothing else beyond user/login and what the site's forms need.
• To do: Members-only content is in its own section, read by a role assigned to the members' group, not just hidden.
• To do: Editor roles are limited by class and subtree; no editor role has setup/*, role/* or user/* beyond need.
• To do: Roles are assigned to groups; members and staff are in different groups.
• To do: Access was tested with test accounts at example.invalid, and ./console exp:accesscheck explains every surprise (Sections, roles and policies).

Templates and output #

• To do: Every value you print yourself goes through |wash(); datatype output comes from attribute_view_gui (Wash and escaping).
• To do: No <style> blocks, style="" attributes, inline scripts or javascript: links in templates, so a Content Security Policy can be enforced (CSP-safe design, Content Security Policy).
• To do: Editors cannot store markup: rich text has no tag for scripts; custom tags instead of pasted HTML (Rich text).
• To do: No visitor-specific data in shared caches (Caching for CMS developers).

Forms and uploads #

• To do: ezformtoken is active and every form keeps the hidden fields the original template prints.
• To do: Public forms have a captcha datatype; collected answers are removed on a schedule (Forms and information collection).
• To do: Upload types are limited to what editors need; file attributes have a maximum size.
• To do: Self-registration is on only where needed, with e-mail verification (Users and registration).

Your own code #

• To do: Every module view declares a policy function and checks it; writes need POST and the form token.
• To do: SQL goes through eZPersistentObject or eZDB with values escaped (escapeString()) and IDs cast to integers (eZDB).
• To do: Redirects go only to addresses of the site (Safe redirects).
• To do: Content is created through the kernel API, as a dedicated user with exactly the rights needed (Content from PHP).
• To do: The book's rules are met: Security in extensions.

APIs #

• To do: rest.ini [Authentication] RequireAuthentication=enabled (shipped) and RequireHTTPS=enabled.
• To do: One account per client, with a role limited to what it needs; API keys with scopes and an expiry (The REST API, Personal API keys).
• To do: Keys and tokens live in environment variables or secret stores, never in repositories.

Configuration and deployment #

• To do: Debug output off on staging and live, or limited to your address; PHP display_errors=Off.
• To do: settings/override/ is not in any repository and not copied between machines.
• To do: Code is read-only for the site's user; workers and cronjobs never run as root.
• To do: ManagedByDeployment=enabled where configuration comes from version control (Deploying a site).
• To do: The rewrite rules of the web server keep settings/, var/ internals and source files from being served (Security hardening, chapter 13).

Accounts #

• To do: The installer's administrator password changed and var/log/initial-admin-password removed (Change the admin password).
• To do: A personal administrator account per person; two-factor sign-in for administrators (Two-factor sign-in).
• To do: Password rules decided (MinPasswordLength, WeakPasswordCheck, [PasswordSettings]).
• To do: Demo mode off (EXP_DEMO_MODE not set) (Demo mode).

Go-live hardening #

• To do: HTTPS everywhere, HSTS, secure cookies.
• To do: The administration on its own host or restricted by network.
• To do: Request rules or the request shield in front, first monitoring, then enforcing (Request rules).
• To do: The setting-by-setting list: Go-live checklist.

Watching and reporting #

• To do: Audit alerts go to a person and the trail leaves the machine (Security and audit).
• To do: Logs are read weekly; backups are off the machine and a restore was tested.
• To do: Updates of Exponential and its extensions are followed and tested.
• To do: Your team knows how to report a vulnerability (Reporting a vulnerability).

Related pages #

• Security standards
• Security review checklist for hosts
• Project launch checklist
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.