Skip to main content

Security policy

This document covers our security practices and policies. If you're interested in the data we collect about our customers please see our privacy policy.

General practices

  • All staff complete GDPR training provided by an external facilitator. It is a requirement for all new members of staff to undertake GDPR training

  • Our development team are Mac based so their machines are fully encrypted using MacOS FileVault

  • Firewall is enabled and all machines, Mac and PC, are set to require a password to access them after they go to sleep

  • Our PCs are protected by anti-virus software and anti-malware software

  • We are careful to never share sensitive information using plain text or non-encrypted platforms

Passwords

  • We never share client passwords externally

  • Passwords are securely stored in Zoho Vault

  • For our own passwords, we use strong, randomly generated passwords created by Zoho Vault that are never re-used

  • Passwords are never sent in plain text by email

  • Our password vault is separated into containers. Only the people who need certain passwords are able to access them

  • Users who leave the company have their access to Zoho Vault and all systems revoked

Website security

General

  • We encrypt all sensitive client data, like passwords, using Zoho Vault or similar

  • For clients that have active maintenance contracts, we update Craft and its plugins either monthly or quarterly, depending on the contract

  • We never save passwords in applications that grant access to the database or files via FTP

  • Online web applications which store client information are secured with Two Factor Authentication where possible

Development practices

  • Code is version controlled using BitBucket and all employees and contractor's code is subject to review by at least one other person before it can be merged and deployed into the production

  • Code is tested in a staging environment before being deployed to production

Access control

  • Access to all servers, source code and all third-party applications are secured with two-factor authentication, where possible

  • Developers and contractors are only given the lowest level of access that allows them to work

  • Developers are required to sign either a contract of employment or contractor service agreement, as appropriate, covering confidentiality and GDPR, before being given access to any client data

  • Developers are only given access to the site they are actively working on

  • Once a developer is no longer working on a site, their access to the server and repository is revoked

Craft CMS

We follow the Security best practices published by Craft CMS. These include:

  • Placing the project’s source folder above your webroot

  • Disable the Settings area of the Craft control panel in non-development environments (i.e. staging and production) by setting the allowAdminChanges config setting to false

  • We explicitly set the @web alias for the site

  • We install an SSL certificate and enforce it

  • Enabling the “Purify HTML?” setting for all Redactor fields

  • Enabling CSRF protection for all forms

  • Using the latest major version of PHP and upgrading existing sites when they move to new servers

  • Reviewing the file permissions and setting them according to Craft’s installation guide

  • Reviewing the General Configuration settings on a per-site basis during development

  • Setting applicable security headers during development

  • Changing the cpTrigger from the default /admin

  • Removing the X-Powered-By: Craft CMS header

  • Disabling or deleting inactive CMS user accounts

Craft plugins must be from a reputable developer. Wherever possible, any plugins installed:

  • Have good documentation

  • Have at least 100 active instals

  • Be actively maintained (updated within the last 3 months)

  • Have a good response time for GitHub issues

  • Have a version number above 1.x

Additionally we store sensitive information (i.e. passwords and API keys) that are required for certain website functionality outside of Craft. This information is instead stored in a private and publicly inaccessible environment file, which we can securely reference from within Craft. The security benefit of this is that this sensitive information does not end up in the website repository (via Craft’s Project Config files) or the website database.

Monitoring

To ensure the ongoing integrity of a website:

  • We recommend installing Sherlock — a plugin that checks Craft CMS security settings

  • Also we recommend running penetration tests on a monthly or quarterly basis, budget permitting

Data retention policy and data encryption

  • Data retention can be set on a per-form basis, where the form plugin can be configured to retain submission data for a set number of minutes, hours, days, weeks, months or years

  • As PII data can be encrypted, storing data for a short period of time is acceptable, but it should not be stored indefinitely. Configuring the form plugin to purge data inline with your data company-wide data retention policy would make sense.

  • As an IP Address can not be encrypted, we would also recommend not collecting IP addresses as this is recognised as PII. By default, this feature is disabled so no IP addresses are stored in the database

  • The Enable Content Encryption setting can be enabled for: Address, Email, Hidden, Multi-Line Text, Name, Phone, Recipients and Single-Line Text fields. This will encrypt submission content in the database, preventing human-readable data for sensitive fields

  • Please note that the data will appear decrypted in Craft, so anyone with access can view the PII data. Access can be controlled to any form on a User Group or per (Craft CMS) User basis — reducing the risk of accidental access

  • Craft CMS has an admin user group. Members of this user group have full permissions and will have access to all form data

Hosting

  • Access to the host’s control panel is gained via a typical login, which is further protected by Two-Factor Authentication (2FA)

  • Access to external database connections is blocked by default for security reasons, but this can be overridden when required

  • Remote access to the database is done using TCP/IP. This requires a username and password in addition to a Host value and a Port value. These details must all be correct and are obtained via the Access Control page in the host’s control panel

  • Access can be further limited via IP address whitelisting/blacklisting

  • The project itself runs on its own internal network which is protected by a hardware firewall

  • SSL certificates are provided as standard

  • Database data is triple replicated and encrypted at rest using LUKS (Linux Unified Key Setup). Backups are encrypted at rest within object storage

Cloudflare

We use Cloudflare to provide an extra layer of protection against DDoS.

For domains managed by us on Cloudflare, we also:

  • Enforce HTTPS via Cloudflare

  • Enable HSTS via Cloudflare with a max-age of 6 months

  • Automatic HTTPS Rewrites

Access control and logging

Craft CMS

Craft CMS provides granular control over user permissions, so access can be easily restricted to stop users or members of a predefined User Group gaining access to content with Craft CMS.

Typically, there will be three predefined user groups:

  • Admin

  • Client admin

  • Client user

Admin

Every Craft CMS website has to have at least one Admin user. This user has permission to access everything within Craft CMS.

Client admin

As the Admin user is essentially a super user, we rarely assign a client team member to this user group — as there is a chance the user can inadvertently break things. We therefore create a Client admin group which has complete access to all areas within Craft CMS, including user management, but excludes access to settings.

Client user

This user has full access, like the Client admin, but they do not have access to user management.

Other user groups

If required, it is possible to create other user groups that, for example, have limited access to certain sections of the site or can create entries but not publish them. As the requirements change from client-to-client, we will discuss what user groups are required by the client following the project commission.