Security and privacy

Databuddy provides cookieless collection and controls for the information you send. This page describes those controls and their limits. See the Privacy Policy and Data Processing Agreement for our data-protection commitments.

Privacy-first design

The browser tracker uses first-party localStorage for visitor information and sessionStorage for sessions. Session IDs use a 30-minute reuse window; a continuously open page can keep its current session longer.

Standard analytics event records omit raw IP addresses after request handling and approximate country, region, and city lookup. By default, ingestion hashes visitor IDs with a rotating daily salt. Your website's anonymizeVisitorIds setting can disable that transformation or apply it according to the visitor's country.

The identify API links activity to profile IDs and traits you supply. Profile IDs are separate from visitor-ID anonymization. Page paths, titles, custom properties, and errors can also contain personal information; review those payloads before sending them.

Privacy controls

Enable the features you need using the SDK configuration. For example, this configuration disables errors, outgoing-link events, and performance collection:

import { Databuddy } from "@databuddy/sdk/react";

<Databuddy
  clientId="YOUR_WEBSITE_ID"
  trackWebVitals={false}
  trackOutgoingLinks={false}
  trackErrors={false}
/>;

This is a collection example, not a consent configuration. Where prior consent is required, delay mounting the component or loading the script until consent is granted.

Local data storage and opt-out

The browser tracker honors Global Privacy Control, Do Not Track, and the stored opt-out preference. Its built-in helpers are:

window.databuddyOptOut();
window.databuddyOptIn();

Opting out stops tracking, clears local tracker identifiers, and stores the preference when localStorage is available. Opting in does not override GPC or DNT. These helpers do not delete information already collected on the server.

Data deletion in practice

Visitors should contact the website owner about collected information. We assist customers with access, correction, and deletion requests; contact privacy@databuddy.cc. Hashing an identifier or leaving identification disabled does not guarantee that no personal data was collected.

Access control settings

Collection requires an active website ID. Origin filtering is an ingestion control, not proof of domain ownership: a non-browser client can supply an Origin header.

Open your website's Settings → Security to configure additional allowed origins and IP restrictions.

Allowed origins

When a request includes an Origin, the registered hostname and its subdomains are accepted by default. Additional allowed origins broaden that set; they cannot exclude the registered domain.

Without a configured list, requests lacking an Origin are accepted. With a nonempty list, a missing or unrecognized Origin produces a 403 response.

Supported entries include:

  • example.com: the hostname.
  • *.example.com: the apex and its subdomains.
  • localhost: local development.
  • *: any parseable origin.

Matching uses the hostname, not a particular scheme or port. The origin check does not itself enforce HTTPS.

Allowed IP addresses

An empty list imposes no IP restriction. A configured list accepts only requests with a trusted matching IP address; other requests receive a 403 response.

Supported entries include individual IPv4 or IPv6 addresses and IPv4 CIDR ranges, such as 192.0.2.10 or 192.0.2.0/24.

This path uses the trusted cf-connecting-ip header. It does not fall back to arbitrary x-forwarded-for or x-real-ip values.

Test restrictions with the actual clients and infrastructure that will send events. Blocking legitimate sources prevents their data from being collected.

Account security

Two-factor authentication

Open Settings → Account in the dashboard and choose Enable next to two-factor authentication to protect your login with an authenticator app such as 1Password, Authy, or Google Authenticator. Accounts created with Google or GitHub set a password first, because turning two-factor authentication on or off asks for it.

Once it is on, every way of signing in asks for a code after the first step, whether you use your email and password, a magic link, or Google or GitHub. Turning it on also signs your account out on every other device within a few minutes, so a session you did not start cannot outlive the change. You can check Trust this device on the code screen to skip the code on that browser for 30 days.

Setup gives you single-use backup codes. Store them somewhere other than the device that runs your authenticator app, and use one on the code screen if you lose that device. You can create a fresh set from Settings → Account at any time, which makes the previous codes stop working.

Repeated wrong codes lock two-factor sign-in for 15 minutes. We email the account owner whenever two-factor authentication is turned on or off and whenever new backup codes are created, so an unexpected email is a reason to reset your password.

Losing your authenticator and backup codes

If you are still signed in on any device, you do not need support: open Settings → Account there and turn two-factor authentication off with your password.

If you are signed out everywhere and can no longer produce a code, email support@databuddy.cc from the address on your account and tell us which of your websites you can publish a DNS record on. Because anyone who reads that inbox could send the same request, recovery also needs proof that you control that website's domain. It must belong to an organization you own, and you must have set its domain yourself at least 30 days ago. We send you a DNS TXT record named _databuddy-recovery.<your-domain>, and you publish it directly on that name rather than through a CNAME.

We also email you as soon as the request is opened, and the reset only happens after a two-day waiting period. Signing in to your account during that time cancels the request, so if you did not ask for it, sign in and change your password. After the waiting period, we turn two-factor authentication off, sign your account out on every device, remove trusted browsers and connected app tokens, and email you again. You can then sign in, set it up again, and delete the TXT record. Support recovery is not available for accounts without an eligible website until independent approval can be authenticated. Keep your backup codes somewhere you can access if you lose your authenticator.

Data protection

Requests are validated, size-limited, and rate-limited. Profile display names and email addresses use AES-256-GCM field encryption when the server key is configured; production ingestion requires that key. Arbitrary event properties and profile traits are outside this field-encryption mechanism.

Infrastructure, AI, billing, and delivery services process information needed for the features you enable. See the Data Policy for their roles.

Privacy compliance

Cookieless collection does not automatically remove consent requirements. Review browser storage, the information collected, and applicable rules. See the web analytics privacy guide.

Implementation security

Content Security Policy

Allow the tracker CDN in script-src and the configured ingestion endpoint in connect-src. For the default hosted endpoints, those are https://cdn.databuddy.cc and https://basket.databuddy.cc. Merge these into your existing policy; do not replace your application's other restrictions.

Support and questions

How is this guide?