At Kindly, we take security seriously to ensure that no data ever gets in the hands of unauthorized users. This is achieved by putting security first and building and deploying the platform using applications where security and privacy is a top priority.
We build Kindly using the Django web framework. Django is a Python web framework for large-scale web applications, used by companies such as Mozilla, Pinterest, Instagram and NASA. Django comes with a range of security features already built-in, described below.
XSS attacks allow a user to inject client side scripts into the browsers of other users. Django templates protect us against the majority of these XSS attacks.
CSRF attacks allow a malicious user to execute actions using the credentials of another user without that user’s knowledge or consent. Django has built-in protection against most types of CSRF attacks by including a secret in POST requests, which we have enabled in our backend system.
SQL injection is a type of attack where a malicious user is able to execute arbitrary SQL code on a database. By using Django’s querysets, the resulting SQL will be properly escaped by the underlying database driver.
Clickjacking is a type of attack where a malicious site wraps another site in a frame. Django contains clickjacking protection which in a supporting browser can prevent a site from being rendered inside a frame.
We deploy our site behind HTTPS with TLS to ensure that there is no unauthorizated access to information tranferred between the client and the server, including cookies.
All passwords are encrypted in Django using the PBKDF2 algorithm with a SHA256 hash, requiring massive amounts of computing time to break.
Kindly is hosted on multiple cloud providers with data center locations in the following availability zones in the EU, all of which are ISO 27001 certified:
Amazon Web Services (AWS) in the region
Heroku in the AWS region
Google Cloud Platform (GCP) in the region
Heroku is used for deploying, running and managing the platform. Heroku is a cloud service for delivering, monitoring and scaling web applications, used by companies such as Microsoft, Toyota, Atlassian and Salesforce. Heroku is designed to protect customers from threats by applying security controls at every layer and isolating customer applications and data. Heroku works closely with external security assessors to review the security of the Heroku platform and applications and apply best practices. Heroku comes with a range of security features already built-in, described below. Heroku’s physical infrastructure is hosted and managed on Amazon Web Services (AWS) within Amazon’s secure data centers.
Each application on the Heroku platform runs within its own isolated environment and cannot interact with other applications or areas of the system. This restrictive operating environment is designed to prevent security and stability issues.
We store all customer data securely in a PostgreSQL database in Heroku, where all customer data is stored in separate access-controlled databases per application. Each database requires a unique username and password that is only valid for that specific database and is unique to a single application. Furthermore, connecting to Heroku Postgres databases requires TLS encryption to ensure a high level of security and privacy.
Please see their extensive security documentation describing security measures and certifications.
Heroku utilizes firewalls to restrict access to systems from external networks and between systems internally. By default, all access is denied and only ports and protocols that are explicitly approved by us are allowed.
Heroku provides DDoS mitigation techniques including TCP Syn cookies and connection rate limiting in addition to maintaining multiple backbone connections and internal bandwidth capacity that exceeds the Internet carrier supplied bandwidth.
Heroku provides daily backups of applications and data on secure, access-controlled and redundant storage. These backups allow Heroku to deploy our application across their platform and to automatically bring the application back up in the unlikely event of an outage.
We use Pusher to handle the communication between the bot and the end-user, utilizing the publish-subscribe pattern. Pusher is an infrastructure-as-a-service company for integrating realtime messaging and is used by companies such as GitHub, The New York Times and MailChimp.
The communication in the chat window between the end-user and our backend is securely transmitted in a private Pusher channel. The Pusher client is set up with our unique application key and each chat session is given a private channel for communication. All incoming messages are authenticated to ensure that only authorized users has access to the channel and can send messages to and receive replies from the bot.
The security and encryption methods of the chat bubble is explained in the diagram below:
User connects to bot by activating chat bubble.
Server creates encrypted token using AES 256 + secret and returns token to user.
User tries subscribing to chat channel using returned token as part of channel id.
Pusher initiates auth request to bot server appending token as a header parameter.
Server deciphers and validates token and returns signed authentication token.
Channel subscription succeeded. Websocket connection is live at this point.
User requests greeting message.
Bot sends greeting message to Pusher.
Pusher sends greeting to user through websocket connection.
Bot sends reply message to Pusher.
Pusher sends reply message to user using websocket connection.
Again, explained using a sequence diagram:
default-src 'self' https://*.kindly.ai https://*.kindlycdn.com https://*.pusher.com wss://ws-eu.pusher.com wss://ws-eu.pusher.com:443 wss://sage.kindly.ai;img-src 'self' https://*.kindlycdn.com data:;script-src 'self' 'unsafe-inline' https://chat.kindlycdn.com;style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;object-src 'none';font-src 'self' https://fonts.gstatic.com data:;
All of Kindly's chat logs are stored securely in Amazon Web Services' data centers in Ireland (eu west). Only bot owners, authorized administrators of the Kindly team or collaborators with proper permissions can access chat history. Personal data are never sold or brokered in any way to third parties.
Kindly Chat for web integrations does not store any meta information about the user chatting with the bots, such as IP address or location data.
For bots connected to Facebook, Kindly will only store the user's Facebook ID, full name and avatar URL.