Articles in this section

See more

Developer security and data guidelines

Avatar
John Brennan
  • Updated

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 exhaustive and are subject to change with evolving security best practices.

Application Security

The following 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 SSL/TLS is recent and free of major vulnerabilities – aiming for a high grade on a scanning tool, like an A+ on Qualys SSL Server Test, can make this straightforward.
  2. Ensure the App Key and App Secret are secure and private. We recommend using environment variables to store the values securely on a server and not storing them in public source repositories like GitHub (or, if they must be stored in a repository, encrypting them using ejson). Your App Secret and App Key are how your application identifies itself to Clio — anyone with access to these may be able to impersonate your application. 
  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. 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. We highly recommend using the bcrypt hashing function with at least a work factor of 10, as bcrypt includes built-in salting.
  5. Have a public document describing your vulnerability management and patching workflow, including your timeline to resolve high, medium, and low severity security issues. For reference, Clio’s security policy dictates ASAP fixes for high severity issues, 3 business days for medium, and 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. Use security scanners and automated code analysis tools (for example, brakeman, bundler-audit, retireJS). Static code analysis tools are an important first line of defense in identifying dangerous or exploitable code

Data Security

In addition to application security, it’s important to Clio customers that we carefully manage how data is stored, where it resides, what systems it 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 leaked through log files.
  2. Be aware of all types of data that you receive and store from Clio’s API. Only request and store information that you require for the purposes of your application. Additionally, you should have data access controls to protect personal information and comply with regulatory requirements relating to the processing and storing of personal 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 (e.g. under GDPR and CCPA)
  4. Ensure the application meets the data residency requirements of any region where your application operates. Depending on the type of information being processed, there may be strict requirements that the data not leave the region or jurisdiction.
  5. Identify and track all 3rd party providers or services in use (e.g. 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

The following items 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 attestations or certifications such as SOC2, ISO27001, PCI DSS
  3. Following the best practices as described in Minimum Viable Security Product

Below are a few red flags that can lead 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. Proof of inability to meet DTOS requirement of customer data removal. 
  4. Lack of security policy or privacy policy documentation
  5. Indication that passwords or secrets are stored in unencrypted, publicly accessible locations (e.g. secrets included in source on public GitHub repos). In some cases, passwords or keys may be stored unencrypted on restricted locations where access controls are in place (e.g. on a private CI/CD system)

Supporting your App

Providing customer support for an integration is the responsibility of the app developer. Developers can reach out to Clio’s api support team at api@clio.com for resolving issues pertaining 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.