Security

Last updated: 4 October 2026

Infrastructure

Metrickle runs on Cloudflare. The service uses:

• Workers to run the application code.
• D1 databases.
• KV key-value storage.
• R2 object storage, kept private, for session replay recordings and feedback screenshots.
• Queues for background work, with a dead-letter queue so failed jobs are set aside rather than lost silently.
• Rate Limiting on data collection.
• Email Sending for email from Metrickle.

Where data is stored

Analytics data (events, the session replay index, replay recordings, feedback screenshots and heatmap page snapshots) is stored per workspace in one location, in Cloudflare D1 and R2. By default that storage has no jurisdiction restriction, so Cloudflare decides where it sits.

EU data location for Enterprise workspaces is being set up and is not live yet. Email chris@metrickle.com if you need it, and we will confirm when it is available before any of your data arrives.

Wherever analytics data is stored, account details (sign-in, workspaces, members, billing), app and survey settings, feedback text and study participants' contact details are kept in one global account database.

Connections and HTTPS

All traffic to Metrickle is served over HTTPS. Requests to http:// or www. addresses are redirected to https://metrickle.com.

The metrickle.com website and the dashboard send these security headers (the dashboard allows framing by its own pages only):

• Strict-Transport-Security for one year, including subdomains.
• X-Content-Type-Options: nosniff.
• Referrer-Policy: strict-origin-when-cross-origin.
• X-Frame-Options: DENY, so the site cannot be framed by another page.
• A Permissions-Policy that turns off the camera, microphone and geolocation.

Sign-in and sessions

You can sign in to the dashboard with an email address and password, or with GitHub or Google if you choose to.

• Passwords must be 10 to 128 characters long.
• Passwords are hashed with scrypt before they are stored. Metrickle never stores the password itself.
• A session lasts 7 days, unless your workspace sets a shorter limit.
• Two-factor sign-in with an authenticator app is available to everyone, with one-time backup codes. After 10 wrong codes in a row, two-factor sign-in locks for 15 minutes.
• Session cookies are HttpOnly, so page scripts cannot read them; Secure, with the __Secure- prefix, so they are only sent over HTTPS; and SameSite=Lax, so they are not sent with most cross-site requests.

Workspaces and roles

Apps belong to a workspace. Each person in a workspace has a role, and can be limited to some of its apps. People join through an invite link, single sign-on or SCIM.

Workspaces can also make their own roles from a list of permissions. Nobody can grant a permission they don't hold themselves.

Workspace security settings

Owners and admins can set rules for everyone in their workspace. They apply on every request, including to sessions that are already open.

• Require two-factor sign-in. Signing in through the workspace's single sign-on counts.
• Single sign-on with SAML or OIDC (Okta, Microsoft Entra ID, Google Workspace and others), on Pro plans and above. A connection only signs people in once the workspace proves it owns the email domain with a DNS record. Workspaces can require it; owners can still sign in with a password and two-factor, so an identity provider outage can't lock everyone out.
• SCIM provisioning on Enterprise: your directory adds and removes people, and its groups set their roles. Deactivating someone removes their access at once. SCIM never changes or removes an owner.
• Maximum session length, after which people sign in again.
• IP allowlist, which applies to API tokens too.
• Retention period for events, replays and feedback, deleted daily after that.
• Replay off, or all text masked, for every app at once, whatever each app's own setting.

Nobody can save a rule that would lock themselves out, such as an IP allowlist that doesn't include their own address.

Audit log

Each workspace has an audit log that owners and admins can read and export as CSV or JSON Lines. It records:

• Every change made through the dashboard or API, by whom, from which IP address and browser, or by which API token.
• Every time someone watches a replay, sees a feedback screenshot or a study participant's details, or exports raw events.
• Changes to members, roles, invitations and security settings, and people added or removed by SCIM.
• Metrickle support sessions, with the reason given, and retention clean-ups.

When a visitor's data is erased, the log keeps only a hash of their id.

API tokens and AI assistants (MCP)

AI assistants connect to the MCP server with OAuth 2.1: the assistant signs in with the person's Metrickle account, and the person approves it on a Metrickle page.

• The approval page names the app that's asking, says whether Metrickle could verify that name, and shows where the person will be sent back to. It warns when the app runs on the person's own computer.
• The person picks one workspace and Read or Read and draft. The assistant never has more access than the person has at the time of each request, and never gets permissions only a person can use.
• PKCE (S256) is required. Access tokens last an hour and are accepted only by the MCP server. Refresh tokens change on every use; if an old one is used again, or a sign-in code is used twice, the connection ends.
• Only SHA-256 hashes of tokens, codes and client secrets are stored. People can disconnect an assistant at any time, and approvals and disconnects are recorded in the workspace's access log.

Personal API tokens give access to the /api/v1 API and to the MCP server, for scripts and clients without OAuth.

• A token starts with mk_sk_ followed by 32 random characters. It is shown once when you create it. Metrickle stores only a SHA-256 hash of it, so a lost token cannot be shown again, only replaced.
• A token acts as the person who created it, with that person's role in each workspace. It never has more access than they do.
• There are two scopes. Read tokens can only read. Read and draft tokens can also create goals, funnels, tasks and survey drafts, and edit survey drafts.
• No token can delete, archive or erase anything, rotate keys, change settings, or create or revoke tokens.
• Surveys created with a token stay drafts until a person activates them in the dashboard.
• Tokens can expire after 1 to 365 days, or have no expiry. Revoked and expired tokens are rejected.
• Each person can have up to 20 active tokens.
• The MCP server is stateless and accepts bearer tokens only: OAuth access tokens or personal API tokens, never cookies.

Data collection from your apps

Your apps send events to Metrickle using a public write key (mk_pub_…). The write key identifies which app the events belong to. It is not a secret, because it appears in your web pages, so Metrickle limits what it can be used for:

• Origin allowlist: each app can list up to 20 domains (subdomains included) that are allowed to send events.
• Rotation: owners and admins can rotate an app's write key at any time.
• Rate limit: 600 requests per minute for each write key and IP address.
• Size limits: a batch can be at most 256 KB and 100 events.
• Bots: requests from known bot user agents, or with no user agent, are dropped.
• Clocks: timestamps from the device are corrected for clock drift, and cannot be set more than 7 days in the past.

Session replays and screenshots

Session replay recordings are stored as compressed chunks in private Cloudflare R2 storage. They are not publicly reachable: they are only served through the dashboard API, which requires you to be signed in.

Screenshots attached to feedback are optional, limited to PNG, JPEG or WebP images of up to 2 MB, and stored in private R2 storage.

How replays are masked and when they record is described on Data and privacy.

Reporting a security issue

If you think you have found a security vulnerability in Metrickle, please email security@metrickle.com with the details and steps to reproduce it. Please do not access other people's data or disrupt the service while testing.