Security

Encryption

• At rest. Calendar provider tokens, Apple app-specific passwords, your application’s client secrets, and the title, description, location and link of every stored event are encrypted with AES-256-GCM before they reach the database. So are an event’s people and its meeting link: the organiser, the guest list with names, email addresses and replies, and the join address.
• Bound to their record. Each encrypted value is tied to the record that owns it, so a value copied onto another record does not decrypt.
• In transit. The API, the connect pages and webhook deliveries use HTTPS. Webhook callbacks must be HTTPS addresses.
• Key management. Every stored secret is encrypted with a data key that AWS Key Management Service issues and wraps, a separate one per customer organisation. KMS refuses to unwrap one organisation’s key for another, every use of a key is logged, and keys are versioned so they can be rotated.

Tokens and secrets

• Access tokens, refresh tokens, authorisation codes and link tokens are stored only as SHA-256 hashes. They are shown once, when issued.
• Access tokens expire after three hours. Revoking a connection ends every token issued for it.
• Secrets, event text, guests’ names and email addresses, and meeting links are kept out of application logs, and the API request log removes them before anything is stored.

An application that switches on Cronofy compatibility mode gets the same token back when it asks twice, as Cronofy does. For those applications only, tokens are also kept in encrypted form, under the same per-organisation keys as every other secret.

Keeping customers apart

• Every record that belongs to a customer carries that customer’s organisation and application, and every database query made for a request is filtered by both.
• Asking for another customer’s record gives the same answer as asking for one that does not exist.
• Code review rules stop request handlers from reaching the database directly, and automated tests check that one application’s token cannot read another’s data.

Least-privilege access to calendars

• Google: events and the calendar list only (calendar.events, calendar.calendarlist.readonly), plus the account’s identifier and email address. No access to mail, contacts or files.
• Microsoft: calendar read and write (Calendars.ReadWrite) and the permission needed to stay connected, with no administrator consent required.
• Apple iCloud: Apple offers only app-specific passwords, which Apple does not limit to calendars. CalMonkey uses one solely to reach calendars and treats it as its most sensitive secret.

Guests, repeating events and meeting links use these same permissions; nothing wider is asked for. CalMonkey stores no attachments, and keeps events only from 42 days in the past to 201 days ahead.

Invitations to guests are sent by the user’s own calendar provider, from the user’s own account. CalMonkey sends no email to guests, and holds a guest’s name, email address and reply only as part of the event they belong to.

Deletion

• Revoking a connection ends its tokens and deletes its stored events, with their guest lists and meeting links, during the request itself.
• A follow-up job then stops the provider’s change notifications, withdraws CalMonkey’s permission at the provider where the provider allows it, and deletes the stored credentials and calendars, within 24 hours.
• The API request log and webhook delivery records delete themselves after 30 days (request log: 7 days on the Developer plan).

Webhooks

• Every notification is signed. The signature covers a time stamp as well as the body, so a captured notification cannot be replayed later, and each channel has its own signing secret.
• Callback addresses are checked when a channel is created and again before every delivery: HTTPS only, and never a private, local or cloud-metadata address. The connection is pinned to the address that was checked, and redirects are not followed.

Hosting

• The API, the database and its backups run in Amazon Web Services’ Sydney region, in Australia. Backups are encrypted.
• The database is not reachable from the internet.
• Rate limits per application and per connected account stop one customer’s runaway loop from affecting others.

Reporting a vulnerability

Email security@calmonkey.com with what you found and how to reproduce it. We will acknowledge your report within 3 business days, keep you informed, and will not take legal action over good-faith research that avoids other people’s data and does not disrupt the service. See also the privacy policy and the sub-processors.