Security

Effective date: October 4, 2026

This page describes the security measures built into TalkingDot and how to report a vulnerability. We describe what we actually do and do not claim certifications we do not hold. No online service can be perfectly secure, so we also give you controls to limit the data you collect.

Encryption in transit

TalkingDot is served over HTTPS, so data travelling between browsers, the messenger and our servers is encrypted. Plain HTTP requests are redirected to HTTPS, a Strict-Transport-Security (HSTS) header tells browsers to use HTTPS only, and dashboard cookies are marked Secure.

Account security

• Password hashing. Passwords are stored only as one-way hashes, using Argon2id where the server supports it and bcrypt otherwise. We never store or email passwords in readable form.
• Two-factor authentication. Every teammate can turn on time-based one-time codes (TOTP) from an authenticator app, with recovery codes for emergencies.
• Brute-force protection. Sign-in, two-factor, sign-up and password-reset attempts are rate limited.
• Sessions. Session cookies are HttpOnly and SameSite=Lax, and the session identifier is renewed when you sign in.
• Roles. Each workspace has owner, admin and agent roles, so teammates get only the access they need.
• Audit log. Administrative actions in a workspace are recorded with the time, the teammate and the IP address, and kept for one year.

Application security

• CSRF protection. Forms and dashboard requests that change data must carry a secret token tied to your session.
• Content-Security-Policy. Pages are sent with a strict Content-Security-Policy that uses a fresh nonce for every request, plus headers that stop other sites from framing our pages, prevent MIME-type sniffing and switch off browser features we do not need.
• Safe rich text. Rich text, such as help-center articles, is cleaned against an allow-list of HTML tags.
• Safe files. Only allowed file types can be uploaded. Images are re-encoded, which removes hidden metadata such as GPS location, and SVG and HTML files are never accepted. Attachments are served through signed links, in a sandbox.
• Hashed secrets. API keys and messenger visitor tokens are stored as hashes, so a copy of the database does not reveal them.

Messenger security

• Isolated display. The messenger runs inside a Shadow DOM, so your website's styles cannot break or restyle it.
• No cookies. The messenger sets no cookies; it keeps a random token in your website's local storage.
• Domain allow-list. You can limit the messenger to the domains you list, so it does not load on other websites.
• Identity verification. For signed-in users, your server signs the user's ID or email address with HMAC-SHA256 using your workspace secret, so visitors cannot pretend to be one of your users.
• Rate limits and bans. Messages, uploads and new visitor profiles are rate limited, and teammates can block abusive visitors.

API and webhooks

REST API keys belong to a workspace, can be revoked at any time and are rate limited. Every webhook delivery is signed with HMAC-SHA256 over a timestamp and the request body, using a secret unique to that webhook, so your server can check that a request really came from TalkingDot and is recent. Failed deliveries are retried.

Privacy controls

• Store visitor IP addresses in full, truncated or not at all.
• Approximate location is read from Cloudflare headers or looked up in a database on our own server, never sent to a third-party lookup service.
• Have closed conversations deleted automatically after a number of days you choose.
• Anonymous visitors who never chat are deleted after 30 days, and page-view history is kept for 90 days by default.
• Export or erase any contact on request.

Read more in our Privacy Policy and in the security and privacy guide. You can check the current state of the service on our status page.

Reporting a vulnerability

If you believe you have found a security vulnerability, please email hello@talkingdot.com with "Security" in the subject line and enough detail for us to reproduce it. Our security contact is also published at /.well-known/security.txt.

Please give us reasonable time to fix the issue before sharing it publicly, do not access, change or delete other people's data, and do not run tests that could harm the service, such as denial-of-service attacks or spam. We will acknowledge your report, keep you informed and tell you when the issue is resolved.