The Chat-Bot Security Checklist is an exhaustive list of all elements you need to have before launching your chat-bot to production.
It is based on Chat-bot developers' years of experience, with the additions coming from some other open-source checklists.
All items in the Chat-bot Security Checklist are must for the majority of the projects.exception only be made for a regulatory reason. you can use this checklist to implement three-layered defense to your Chat-bot product. Each point in the list is marked as low medium and high.
- means that the item is recommended but can be omitted in some particular situations.
- means that the item is highly recommended and can eventually be omitted in some really particular cases. Some elements, if omitted, can have bad repercussions.
- means that the item can't be omitted by any reason. You may leave a huge vulnerability open to the world. The testing priority needs to be on these elements first.
Before diving right into the checklist, let's ask a question why Chat-bot needs security and what's different with them? And the answer is, most of the components are same like your Infrastructure, Back-end, your middleware and dev-ops practices all are same, the only thing that differs is Language and conversational components of the chat-bot which isn't common in mainstream applications that's where the focus of this checklist.
You might need to deploy your chat-bot to a social platform or you might need a dedicated mobile app or a web SDK that can be used to use your chat-bot in other businesses. In any case, When you are running your code in a machine you have no control, you need to take some measures to ensure few things. Here are some pointers according to their platforms that you need to think about when deploying your Chat-bot -
-
Data: You need to make sure that your customers Data is not available to other apps. and you should also encrypt the data so that it can't be stolen even under physical access.
-
Authentication: There are two types of authentication that You might need.
-
You want to make sure that No, Non-user can access your platform.
-
When your users' device requesting private information you must ensure that your user is requesting the information instead of malicious user with device access. You can do this using FaceID and TouchID they are becoming more and more common with new smartphones.
-
Developing in-house authentication Management system can be vulnerable at times considering you haven't got it pentested yet. So if possible for your organization you can go for an AaaS Provider.
-
Hard-coding: Make sure you are not storing your secrets on your code. Any API access token with admin privilege should not be hard-coded in your App.
-
Channel Authorization: Chat-bots have this unique feature of being available to everyone by deploying the bot on multiple channels like Skype for Business, Microsoft Teams, Facebook, Slack, etc. So If you are planning to deploy your chat-bot in any of the platforms your organization must make sure to restrict features which shouldn't be available to all.
-
Channel Authentication: You should check if your customer is using your platform instead of someone else from his/her account.you can do this using 2-Factor Authentication like OTP SMS or Email, Google Authenticator.
-
regulatory Data Protection: Every regulation restricts customer data ownership to yourself so if you are asking PII(Personally identifiable information) or ePHI(Electronic protected health information) from your customer you must restrict that particular intent to your native channel only. Because you don't have custom SLAs to any of these channel provider, you can't solely own the private data it'll be shared with them.
- Front-end Security If you are a chat-bot as a service company than you must think of secure deployability. for that reason you might SDK for a platform like a web, Android, iOS, etc. then you need your Client Technology secure and tested. you will also need a VAPT in order to work in B2B.This c
-
Intent Segregation: The intent of your chat-bot should be different for a different class of users. since NLP is a probabilistic system instead of being a deterministic system you should not differ response based on user class. you should all together create another intent/instance for a different class of users.
-
Permissioned Intent: You must verify identity then channel and role of your customers before passing it to the intent.you should also check if the intent is there for that particular role or not.
-
Authorization: You must check who is the user. Role Management
- Customer
- Unauthenticated customer
- Authenticated Non-Premium customer
- Premium customer
- Customer
If your chat-bot also has functionality for Internal users then you should have these roles.
-
Internal Roles
- Developer/tester/federated Identities
- Admin these roles will help you in intent Segregation, logging and for audit purpose.
-
Language generation Constraint: you should not directly use your customer input. Because if a malicious user sent you a malformed input it could be dangerous for the system. although it is a very common practice to sanitize input here because of multiple contexts in play. developers forget to sanitize.
-
Rate Limiting queries: Considering the speed of typing of a mobile user ranges 30–75 wpm and reading speed is 250 wpm. if one user takes 5 seconds to read the text and 10 seconds with other UIs then we can assume that on an interactive Bot no. of user calls can be 10 +-5 = max-15 so we can limit our bot API call rate to 15 Per/Minute. By doing this we mitigate the risk of a DOS attack.
-
Life Cycle Management: You should create a system where you mark Conversation as stale and send them to archive. and also if you need to delete them or not. backup should be in place for all the chats.
-
PII and PHI Redaction: You should implement a solution to redact or encrypt the Personally identifiable data. you can do this by storing a key on the user's device. so the user can decrypt and read their Conversation and no one else will be able to read it. but you will be needing these logs for audit purposes.
-
Administration: Create a system where there should be clear access on who can access the conversational data. and also log the data accessing activity to another server where you have the access.
- Injection:
- Broken Authentication:
- Sensitive data exposure:
- XML External Entities:
- Broken Access control:
- Security misconfigurations:
- Cross Site Scripting (XSS):
- Insecure Deserialization:
- vulnerabilities:
- Insufficient logging and monitoring:
- SLAs: Check service level agreement for bot usage. There would be problems if a vendor doesn't support bot accessing their service. It will be no use for you to buy some software which doesn't allow bot access to their service.
If you want to show you are following the rules of the Chat-Bot Checklist, put this badge on your README file!
[![Chat‑Bot_Checklist followed](https://img.shields.io/badge/Chat_Bot_Security_Checklist-followed-brightgreen.svg)](https://github.com/apoorvrajsaxena/Chat-Bot-Security-Checklist)
Open an issue or a pull request to suggest changes or additions.
The Chat-Bot Security Checklist repository consists of two branches:
This branch consists of the README.md
file.
This branch will be used to make some significant changes to the structure, content if needed. It is preferable to use the master branch to fix small errors or add a new item.
If you have any question or suggestion, don't hesitate to use Twitter: