Security

The short version. Responses are stored in the EU and encrypted in transit and at rest. Secret keys are stored only as hashes. Access is limited to the people who run Kibble. If you find a security issue, email [email protected].

This page describes the technical and organizational measures we keep in place. It forms Annex 2 of our Data Processing Addendum.

#Where data lives

• In the EU. Kibble's database, which holds responses, forms and accounts, and the servers that run Kibble are in the EU, behind a network provider that protects them from attacks.
• AI triage. If a form has triage on, its responses go to our AI provider without contact details such as email addresses and phone numbers. The Privacy Policy has the details.
• Our providers. They're listed, with where they process data, on the Subprocessors page.

#Encryption

• In transit. Traffic to Kibble's dashboard, API and forms uses HTTPS. Connections to the database are encrypted and the database's certificate is verified.
• At rest. The database and its backups are encrypted at rest. Connection strings for customers' own databases are also encrypted before they're stored.

#Keys and secrets

• Hashed keys. Site secret keys and workspace API keys are shown once, when they're created, and stored only as SHA-256 hashes. We can't recover them, only replace them.
• Read-only API keys. Workspace API keys can only read data.
• Signed webhooks. Webhooks are signed with HMAC-SHA256, so your endpoint can check that a request came from Kibble.
• Signed Slack connection. The "Add to Slack" connection uses signed, short-lived tokens. It asks Slack only for permission to post to the channel you pick.

#Personal data in responses

• IP addresses. IP addresses are never stored with responses. Kibble keeps a one-way hash, salted differently for each site, so a visitor can't be matched across sites.
• Query strings and other sites. Page addresses are stored without their query strings, and other sites are recorded by their domain only.
• Refused fields. Kibble refuses form fields that look like passwords, card numbers or social security numbers.
• Spreadsheet safety. CSV exports neutralize answers that a spreadsheet would run as formulas.

#Access control

• No passwords. People sign in with Google, GitHub or a one-time code sent by email. Kibble doesn't have passwords to steal.
• Sessions. Sessions are kept in secure, HTTP-only cookies and checked on every request.
• Roles. Each workspace has owners and members. Only owners can invite and remove people, change roles and workspace settings, delete sites or the workspace, or replace a site's key.
• Our own access. Within Kibble, only the people who run the service can reach production systems, through our providers' access controls. Kibble has no internal tool for browsing customer data. We look at a customer's data only to support them, to keep the service secure, or when the law requires it.

#Protecting forms and the service

• Allowed domains. Browser submissions are accepted only from a site's allowed domains. Sandbox projects accept localhost only.
• Rate limits. Submissions are limited per IP address, per form and per origin.
• Spam filtering. A hidden honeypot field, timing checks, disposable-email checks and, optionally, Cloudflare Turnstile and AI review.
• Outgoing connections. Webhooks, Slack and database destinations can only reach the public internet, never private networks. Every address is checked when the connection is made, which blocks DNS rebinding.
• Browser protections. Pages can't be embedded in other sites (clickjacking protection), and browsers are told not to guess content types.

#Building and running Kibble

• Tests before every deploy. Changes go through pull requests, and nothing is deployed unless the full automated test suite passes.
• Dependencies. GitHub alerts us to known vulnerabilities in our dependencies, and we update them.
• Monitoring. We check production's health every 10 minutes and get alerts on errors. Error reports leave out the content of responses.
• Backups. The database is backed up daily.
• Incidents. If a breach affects customer data, we notify affected customers without undue delay, as the DPA describes.

#Reporting a vulnerability

Email [email protected] with:

• what you found;
• how to reproduce it;
• what an attacker could do with it.

We'll confirm receipt within three business days and keep you updated until it's fixed. We don't run a paid bug bounty yet, but we'll credit you if you'd like.

If you act in good faith, we won't take legal action against you. Acting in good faith means:

• you test only against your own account and data;
• you avoid harming people, data or the service, so no denial of service, spam or social engineering;
• you don't access or keep other people's data beyond what's needed to show the issue;
• you give us reasonable time to fix it before telling anyone else.

Our machine-readable contact details are at /.well-known/security.txt.