Integration security checklist #

This page is for whoever reviews an integration before it goes live, and again once a year. Each item names where to check it. The reasons behind the items are on Security for integrations.

Contents #

1. Credentials
2. Accounts and rights
3. Transport
4. Input and output
5. Logging and audit
6. Data protection
7. Incident readiness
8. Sign-off

Credentials #

• To do: No secret in the extension's repository or its history (search for expk_, expt_, password, secret, key).
• To do: Secrets only in settings/override/*.ini.append.php (kept out of Git) or the environment.
• To do: One credential per integration, environment and purpose; names say which.
• To do: API keys limited to the scopes needed; end dates set; rotation date in the calendar (Personal API keys).
• To do: OAuth client secrets only on servers; oauth/authorize only for the roles that need it.
• To do: Credentials the integrator's staff knew are rotated at handover.

Accounts and rights #

• To do: A service account per integration; no administrator role (Service accounts).
• To do: Policies limited by subtree, class, section and language as far as possible.
• To do: A forbidden call was tried and answered 403.
• To do: Scripts run as the site's operating system user, not root.
• To do: LDAP: dedicated bind account with read rights only; LDAPDebugTrace=disabled.
• To do: SSO handler: the trusted header can only come from the proxy; administrators sign in another way.

Transport #

• To do: HTTPS on every API and webhook, both directions; rest.ini [Authentication] RequireHTTPS considered.
• To do: Certificate verification on for every outbound call.
• To do: SFTP instead of FTP; host keys trusted explicitly.
• To do: LDAP over ldaps://.
• To do: Endpoints that only other systems use are limited to their addresses at the web server, where possible.

Input and output #

• To do: Every value from another system is validated (type, length, allowed characters); ids cast to integers.
• To do: SQL of your own uses (int) and $db->escapeString(); no string concatenation of raw input.
• To do: Rich text converted to an allowed set of elements; no raw HTML into templates.
• To do: URLs: only https/http; unsafe schemes refused.
• To do: File imports stay inside the import directory below var/; sizes limited.
• To do: Outbound calls to addresses from data refuse private and loopback addresses; timeouts and size limits set.
• To do: Endpoints of your own check access (canRead(), policies) and require POST and the form token for writes.
• To do: Answers contain no passwords, tokens or personal data the caller does not need.

Logging and audit #

• To do: One summary line per run in the integration's log; errors in error.log through eZDebug::writeError().
• To do: No secrets or full personal-data payloads in any log.
• To do: The service account's activity checked in the audit after the first runs (exp:audit tail).
• To do: Refusals (access.apikey.use.failed, access.permission.refused) watched.
• To do: If required, security events sent to the SIEM through the syslog or webhook sink (Outgoing webhooks).

Data protection #

These items are practice, not legal advice.

• To do: Every flow with personal data listed with its purpose, fields, recipients and retention.
• To do: Processors (mail provider, AI provider, CDN, SaaS search) known to the customer and covered by agreements.
• To do: Only needed fields are sent; exports deleted when no longer needed.
• To do: Collected form data removed from Exponential when the retention ends.
• To do: Test data anonymized when a production copy leaves production.

Incident readiness #

• To do: The runbook says how to revoke each credential at once.
• To do: The runbook says how to pause each flow (Setup > Cronjobs, Pause).
• To do: Contacts for each other system and for security are listed.
• To do: Vulnerabilities in Exponential are reported privately to [email protected].

Sign-off #

Integration: ...............   Version: .........   Environment: production
Reviewed by: ...............   Date: .........
Open findings (id, severity, owner, due): ...............
Decision: go-live approved / approved with conditions / not approved

Related pages #

• Security for integrations
• Hosting security review checklist
• Accessibility, security and compliance checklists
• Integration go-live checklist
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.