We have a responsibility to take all necessary precautions to protect our website and your data against malicious attempts to steal information, run unauthorised commands, or make illicit changes to databases.
Web security is at the core of all our web applications. We invite any user who discovers a potential vulnerability to contact us in the first instance.
This page gives an outline of the security measures we have taken to comply with our duties as a responsible web-based software provider.
| Area of vulnerability | Mitigation measures |
|---|---|
| Secure connection |
Connection to our server via HTTPS is enforced. Connection to our server is encrypted/authenticated using TLS 1.2 or higher. Our CSP specifies trusted sources for third-party assets and enforces loading via HTTPS. |
| Cross-site scripting attacks (XSS) |
Our CSP specifies trusted sources for third-party assets and enforces loading via HTTPS. Cookies we set are only available on secure same-site connections, rendering them inaccessible to scripting languages. We sanitise all user input (as well as HTML output where it is partially or wholly based on user-generated content). |
| Cross-site request forgery (CSRF) |
A random, unique CSRF token is generated for each user's session. This token is mandatory as part of the request data at all endpoints within our web applications. Endpoints will not respond to any request that contains either no CSRF token or an invalid CSRF token. |
| SQL injection | All queries are prepared or escaped before execution. |
| Server-side template injection (SSTI) | We sanitise all user input, as well as HTML output where it is partially or wholly based on user-generated content. |
| Open redirect vulnerability | All redirects provided in URL parmeters are treated as relative and are prepended with our FQDN before redirection occurs. |
| Insecure direct object reference (IDOR) | Even where a UID or other such reference is revealed in the URL parameters, extensive validation ensures that the user is authorised to view/edit the record requested. There is no identified risk of URL parameters posing a security weakness within our web applications. |
| HTTP parameter pollution | Any effect would be counteracted by IDOR mitigation measures. There is nothing to suggest that HTTP parameter pollution represents a security vulnerability within our web applications. |
| Security misconfiguration |
Debug modes are disabled in live environments. Directory listing in the web browser is disabled. Server software versions are kept at the latest stable release |
| Sensitive data exposure |
All data travels via HTTPS - no exceptions. We do not accept data from anything other than HTTPS connections. Cookies we set are only available on secure same-site connections, rendering them inaccessible to scripting languages. Passwords are stored as a hash created by the bcrypt algorithm, and there is no method of reversing it to reveal the password. |
| Improper function access control | Authentication and authorisation occurs at every single endpoint, no matter how trivial the request, and threads are instantly killed if authentication or authorisation fails. |