Anyone who tells you their system is 100% secure is lying to you. But at Code Poets we are passionate about making all our systems as secure as we possibly can.

We constantly research security issues, and use all of the appropriate best practices, so we are very confident in the service provided.

Code Poets Web Systems include:

• HTTPS Connections: This makes it harder for communication to be hijacked, forged or eavesdropped on.

• Hashed Passwords: This means that when we store passwords, we run them through a special calculation so that no-one can read them. Even if the data could be stolen, this means that no-one would be able to work out the passwords.

• Encrypted Offsite Backups: We make a daily backup of the system which backs up the last 7 days, and weekly backups that have the last 9 weeks. The backups are held offsite because, for example, if there is a fire or flood, there is a backup somewhere else which can be used to restore the system.

To explain the rest of our security protocols, we do need to cover the technical details of what we do, so feel free to review yourself or, ask anyone with a technical/security background, as this list should confirm that we exceed the standards used by the majority of websites:

• Security comes first - we know this sounds obvious, but many web systems try to make things "convenient" first, then try to fix the security holes afterwards (which is not always possible, and always more expensive).

• Assume every request is malicious - these systems are typically available on the internet.

• Pages are served with a very restricted CSP header, this typically includes "unsafe-inline" being off (except for very special cases, e.g. Google maps).

• Password are hashed using the bcrypt algorithm, stored using a crypt() compatible hash, which is intended to be slow to brute force attacks.

• We use HTTPS connections only, along with the SecureTransportSecurity header, so communication between the server and browser is always encrypted, and allows the browser to validate it is connecting to a valid host. We may also implement Public Key Pinning for extra security, but this depends on the website.

• CSRF protection using a value stored in the session (ref cookie), and checked against the same value being present in the POST request (where POST is required for state change operations).

• Cookies are always set with the HTTPOnly and Secure flags set, with a name prefix so the browser can ensure it is always marked as Secure, and for that domain. And depending on the use case, we will also use SameSite cookies.

• All variables are escaped/encoded for the appropriate medium (e.g. html entities and url encoding). This also includes values which should be trusted, such as the output from the date() function.

• Privilege escalation checks are used though-out the codebase, ensuring that every request for a protected resource is made by a logged in user with the appropriate permissions (often using multiple checks to ensure no layer has been bypassed).

• Depending on the situation, login attempts are limited to avoid brute force / dictionary attempts to login under a particular account, but we are also aware of DOS issues this can cause.

• Encryption of relevant data (e.g. backups at rest).

• FTP is avoided as much as possible - however we are aware that some 3rd party software is only capable of using this insecure protocol (SFTP / FTPS are good alternatives).

• Server administration is done over SSH, where the root account is not available externally, and low level accounts can only login with an authorised key pair.

• Server maintenance includes daily updates (up2date, yum, etc), with frequent checks using nmap, the use of sudo, and an automated check for domain and SSL certificate expiry.

• Backups typically done daily to an offsite server, with daily backups of the last 7 days, and weekly backups to the size of the encrypted backup disk (typically 9 weeks), where a complete copy of the website is prepared (in read-only mode) via its own instance of Apache, so the backup can be regularly tested with ease.

• Logs are kept and checked on a regular basis, this includes software updates and the usual linux logrotate on a daily basis, with the Apache 404 and PHP error log being checked on a weekly basis (the PHP logs also report on undefined variables).

• WYSIWYG is avoided for most cases, as it generally makes the inclusion of potentially malicious JavaScript too easy.

If you want to find out more about many of the security risks on the internet, then you can review the content on the OWASP website.