Security

Never paste a Cloudflare Global API Key into Bikfix or anywhere else — it grants full account access with no scoping. Create a dedicated API Token instead, restricted to only the zone(s) Bikfix should manage:

1. 01In the Cloudflare dashboard, go to My Profile → API Tokens → Create Token.
2. 02Start from the "Edit zone DNS" template — it already sets the two permissions Bikfix needs: Zone · DNS · Edit (read and write DNS records) and Zone · Zone · Read (find the right zone for a domain). Don't add anything broader.
3. 03Under Zone Resources, choose Include → Specific zone and select only the domain(s) this client owns — never "All zones". One client, one token, one zone (or that client's specific zones only).
4. 04Leave Client IP Address Filtering and TTL as needed for your own policy — optional, not required by Bikfix.
5. 05Click Continue to summary → Create Token, copy the token (Cloudflare shows it once), and paste it into that client's Connect Cloudflare form in Bikfix.

If a token like this leaks, the blast radius is DNS on the named zone(s) only — not the Cloudflare account, not billing, not other domains.

Each client's Cloudflare token is encrypted with AES-256-GCM before it is written to the database, using a 32-byte key (ENCRYPTION_KEY) that lives only in the server's environment — never derived from a password, never stored alongside the data it protects. It is decrypted in memory only at the moment Bikfix calls Cloudflare's API on that specific client's behalf, and is never written to logs.

Tokens are stored per client, not per agency — an agency managing five clients has five separate encrypted credentials, because in practice each client usually owns their own Cloudflare account. One client's token is never used for another client's domain.

Your Bikfix account password is a separate thing entirely: it is hashed (Node's built-in scrypt), not encrypted — Bikfix cannot recover or view it, only verify it.

Detection, investigation, and diagnosis run automatically. Nothing is ever written to your DNS until a human clicks Approve on that exact proposed change — not on a category of change, on the specific operation shown on screen (record, current value, new value).

Ambiguous drift never gets an auto-proposed fix. If a record has more than one value in play on either side (e.g. a production apex with several A records), Bikfix refuses to guess — it's flagged for manual review instead of turning into an approve button.

Rollback also requires approval. Restoring the previous value after a resolved incident is a second, separate approval — not automatic just because something changed recently.

After a change is applied, Bikfix independently re-verifies it — authoritative DNS, a public resolver, and live HTTP/HTTPS — rather than treating Cloudflare's API returning success as proof the fix worked.

Bikfix is an early pilot-stage product. Specifically, today:

• No formal third-party security audit or penetration test has been done.
• Two incident types are implemented — DNS record drift and Cloudflare 523/5xx origin-unreachable. HTTP/HTTPS redirect and SSL/TLS incident handling described on the homepage are not built yet.
• Cloudflare is the only DNS provider with write access; other providers get manual-remediation instructions and independent verification only.
• Auth is email/password only — no SSO, no MFA, no password-reset flow yet.
• No invite system: every signup creates a brand-new agency, and there's currently no way to add a second person to an existing one.
• Roles (OWNER/ADMIN/MEMBER) are stored but not yet enforced — any authenticated member of an agency can approve fixes and connect or replace credentials today.

If anything here changes, this page will be updated to match — not the other way around.

If you find a security issue, email support@bikfix.co.uk with details. We don't yet run a bug bounty program, but we will respond, fix confirmed issues, and credit you if you'd like.