Articles in this section

See more

Customer data and security guidelines

Avatar
Derek Rawlings
  • Updated

Data Handling & Security

The security of customer data is very important to Clio, and that extends to data our app developers may use and store.

Here is an introductory set of guidelines to help integrators build secure applications, take appropriate care to protect critical user data, and be compliant with applicable regulations, such as GDPR and CCPA. These guidelines shouldn’t be considered complete or guaranteed to make an application secure, but represent a good starting point.

 

Application Security

Following some general Application Security best-practices can reduce the risk of an application being exploited, and mitigate the damage if an exploit does happen:

  1. Require the use of HTTPS, and validate that the version of HTTPS is recent and free of major vulnerabilities by aiming for a high grade on a scanning tool, like an A+ on Qualys SSL Server Test. HTTPS-everywhere ensures all traffic is encrypted in transit.
  2. Ensure the App Key and App Secret are secure and private, for example not including them in public source repositories like GitHub, or using ejson. App Secret and App ID are how the application identifies itself to Clio - anyone with access to these may be able to act as that application, including getting access to data users have granted access to. 
  3. Protect your application against cross-site request forgery attacks, cross-site scripting attacks, and other relevant security vulnerabilities such as the OWASP top ten. These are the critical vulnerabilities that web applications must protect against. A robust defense is important.  Examples of best practices include proper configuration to protect against CSRF, static code analysis to look for XSS and SQL injections, and in a perfect world, regular penetration tests or participation in HackerOne. XSS in particular is a primary concern for web applications.
  4. If your application stores passwords, it must store salted password hashes instead of actual passwords, as described on OWASP. Safe password storage is a security fundamental, and important to mitigating the damage in the event an application is compromised
  5. Have a public document describing your vulnerability management and patching workflow, including your timeline to resolve high, medium, and low severity security issues. Clio is aggressive, and uses ASAP for high, 3 business days for medium, 3 weeks for low for critical applications.  This level of responsiveness may not be realistic for all integrations, but longer than 30-60-90 opens a significant window for malicious exploits.
  6. Take advantage of security scanners and automated code analysis tools (for example, brakeman, bundler-audit, retireJS). Static code analysis tools are an important first line of defence to identify dangerous or exploitable code
  7. Have a public address for users to report security concerns. This is important for both Clio and any customers, to ensure security issues can be communicated and acted upon. It would be great to use something like HackerOne, but a simple email is sufficient, even if that email is a fairly general address, like customerservice@companyname.com.

 

Data Security

In addition to Application Security, it’s important to Clio customers that we carefully manage how data is stored, where it resides and traverses, what a user’s rights are to their data, and what happens in the event of a breach:

  1. Carefully consider what data ends up in log files.  Avoid logging sensitive or personal user information. Sensitive information like passwords, and personally identifiable information like names and addresses can be unintentionally archived or leaked through log files.
  2. Track the types of data you receive from Clio or their users that is processed, stored, or cached by your application. It’s important to understand what, if any, personal information an integration may be processed or stored. It is important to understand what controls are in place to protect personal information and comply with regulatory requirements relating to the processing and /or storing of that information.
  3. Track all countries in which a user’s data will be processed, stored, or transferred. To ensure data security and privacy, all touch points should be considered. It may also be required to disclose these (eg: under GDPR and CCPA)
  4. Ensure the application meets the target jurisdiction’s data residency requirements. Depending on the type of information being processed, there may be strict requirements that the data not leave the jurisdiction.
  5. Identify and track all 3rd party providers or services in use (eg: external web services, hosting platforms like AWS or GCP. Some regions (such as the EU and the state of California) require organizations to disclose all the service providers they use and in what capacity.
  6. Maintain a publicly visible Terms of Service, Security Policy, and Privacy Policy. Data protection laws in Clio’s primary markets (EU, CAN, US) require these policies to be visible to end users (under GDPR, CCPA, and PIPEDA respectively).
  7. Understand which regulations governing security and user privacy are relevant to the application (such as GDPR, CCPA, PIPEDA), and have a plan to be in compliance. If the application is not compliant with applicable laws, it may not be usable by Clio customers.
  8. Document and maintain a business continuity / disaster recovery and incident response procedure. It is important for Clio customers that their tools are available at all times, and that they are informed and aware of any breaches or data issues.
  9. Publicly document any supporting certifications related to your application or organization (for example, security certifications such as SOC2, ISO-27001, and PCI-DSS or privacy certifications such as TRUSTe). These certifications can be an indicator of a strong background in security, and may be needed for regulatory compliance.

 

General Requirements

Below are a few things that will help streamline approval for listing an app on the Clio App Directory:

  1. Demonstrating a 3rd party certification such as the Truste privacy certification
  2. Security certifications such as SOC2, ISO27001, PCI DSS

Below are a few red flags that might make Clio to decline listing an app on the Clio App Directory and/or block Clio Public API access for the App (not an exhaustive list):

  1. No use of HTTPS
  2. Proof of inability to meet data residency requirements, or lack of credible clarity that they could be met
  3. Lack of security policy or privacy policy documentation
  4. Indication that passwords or app secrets are stored in unencrypted, publicly accessible locations (eg: app secrets included in source on public GitHub repos). In some cases user passwords or app keys may be stored unencrypted on restricted locations, eg: on a private CI/CD system with controlled access.  This is acceptable.

 

Supporting your App

Direct customer support is the responsibility of the app developer, who in-turn can reach out to Clio for resolving the issue if it pertains to any of Clio's systems. Please do not redirect customer support requests to Clio. 

 

Support from Clio

Clio takes the availability and stability of our APIs seriously; please report any degradations or breakages to Clio via email to api@clio.com.

 

API rate limits for App Developers

The current API rate limit for app developers is 50 calls / minute / user. The system automatically starts throttling requests above this limit. Do not attempt to bypass or circumvent these limits.