Security at TestDossier

Local-first security model

Unsigned authoring starts in your browser. Test cases, results, and screenshots are stored in IndexedDB and are not sent to TestDossier until you intentionally use a server-backed feature such as sharing, browser capture submission, or cloud sync.

Account and project records are stored in Cloudflare D1. Synced screenshots and other evidence objects are stored in Cloudflare R2. Cloudflare documents AES-256-GCM encryption at rest and TLS in transit for both D1 and R2. These are infrastructure-provider controls; they do not make TestDossier itself Cloudflare-certified.

Passkeys and passwordless sign-in

After signing up, you can enroll a passkey under Account → Security following a recent email-link, Google, or passkey authentication. A passkey uses WebAuthn public-key cryptography: the authenticator keeps the private key and TestDossier stores only the public verification material, a replay counter, device type, backup state, user label, and use timestamps.

• Enrollment and sign-in ceremonies use random, single-use challenges that expire after five minutes and are atomically consumed before verification
• The expected origin and relying-party ID are bound to the exact configured TestDossier hostname; production and preview credentials are intentionally separate
• User verification is required, so the authenticator must confirm a fingerprint, face, device PIN, or security-key gesture
• Discoverable credentials allow email-free passkey sign-in while an opaque user handle avoids exposing TestDossier’s internal account ID
• Stored signature counters are checked and updated with a concurrency guard; registration and verification endpoints are rate limited
• Credential changes require a recently authenticated session. Human access to the operator dashboard additionally requires an allowlisted account authenticated by passkey

Authentication boundary. A passkey is phishing-resistant authentication, but it is not automatically a separate second factor layered on top of email or Google. The local biometric or PIN unlocks the authenticator; TestDossier does not receive biometric data. Email-link and Google sign-in remain recovery methods, so those connected accounts should also use strong MFA.

Magic-link sign-in

TestDossier also uses passwordless email sign-in, so it does not store a reusable account password. The implementation includes the following controls:

• Each sign-in link expires after 15 minutes and can be used only once
• The emailed token is random and stored in the database only as a SHA-256 hash
• Opening the link shows a confirmation page; a same-origin POST consumes it, preventing automated email-link scanners from silently signing in
• A successful sign-in invalidates other pending sign-in links for that account
• New browser session values are stored only as hashes and expire after a maximum of 30 days
• The production session cookie is HttpOnly, Secure, and SameSite=Lax
• Sessions are per-device, capped at three per account; signing in on a fourth device signs out the oldest. Every signed-in device is listed under Account → Devices with a coarse browser-and-OS label, and can be revoked there immediately
• Workspace owners can cap the session lifetime of every member's account (8 hours, 24 hours, 7 days, or the 30-day default). Tightening the cap shortens live sessions immediately, and a workspace owner or admin can sign a member out of every device at once
• Sign-in requests are rate-limited by email and a secret-keyed network identifier; raw network addresses are not stored in sign-in counters

Important boundary. A magic link proves control of the mailbox at that moment. It does not verify legal identity and is not phishing-resistant authentication. Protect the connected email account with its own MFA, and enroll a TestDossier passkey when your device supports one.

Single sign-on with Google or Microsoft

Accounts can also sign in with Google or Microsoft Entra ID (OIDC authorization-code flow; identity tokens are signature-verified against the provider's published keys). TestDossier receives only the verified email address from the identity token — no profile data, contacts, or provider credentials — and links it to the matching account, or creates one on first sign-in. Sign-ins with an unverified email address are rejected outright, which closes the classic unverified-email account-takeover route: Google must assert email_verified, and Microsoft must assert email_verified or the xms_edov (domain-owner-verified) claim. SAML-based SSO and SCIM provisioning are not offered yet.

Account and workspace access

Personal resources are checked against their owner at server API boundaries. Workspace resources require current membership and use three roles: owners hold billing, role changes, and danger-zone actions; admins manage invites, members, renaming, and branding; members read and write workspace data. Every privileged action re-checks the role server-side — a workspace identifier supplied by the browser is treated as context, not as proof of access.

Owners and admins can remove members, and the removed account then fails the server-side membership check. Membership, role, share, and data events are recorded in the workspace activity log, which owners and admins can filter and export as CSV for audit, or pull continuously into a SIEM with a revocable read-only audit-feed token. Cookie-authenticated state-changing requests are protected by SameSite cookies and same-origin request checks. Signed webhooks and bearer-token endpoints use separate authentication appropriate to those integrations.

Shared evidence links

A published report is a frozen copy of the evidence at share time. Editing the working test case later does not quietly change what the reviewer saw. Report URLs are random and non-sequential, and owners can set an expiry, add a password, disable comments, or revoke the report.

New report passwords use PBKDF2-SHA256 with a unique salt. Password attempts are rate-limited per network and across the report to reduce distributed guessing. Older password-protected reports are upgraded to the current password format after a successful unlock.

A share URL is a capability. Anyone who has an unprotected URL can view the report; a protected report additionally requires its password. Use a password for sensitive evidence, set an expiry, and revoke the report when review is complete. A report password is not end-to-end encryption.

Revocation makes the public report, password gate, and preview endpoints return no report metadata immediately. Most report-scoped content is deleted in the same request. A legacy signed report may remain stored but inaccessible while a durable worker finishes exact chunk-digest sealing, then deletes the frozen report, comments, detailed view analytics, one-time codes, and share-build objects. The verdict and verified-signature ledger survives for 12 months with the report title/type, decision timestamps, and a SHA-256 digest of the deleted report payload or chunk manifest; it remains available in the owner's account export and is then purged deterministically. Evidence images also referenced by the underlying project are not deleted merely because one share is revoked, and previews or image URLs already cached by third parties can remain until those caches expire. Do not publish credentials, production secrets, or evidence that should never be independently retrievable.

When verdict email verification is enabled, the one-time code proves only that the reviewer controls the supplied mailbox. It does not prove the reviewer's legal identity.

Access tokens, CI, and uploads

CI ingest and browser capture use random, project-scoped access tokens with explicit capability scopes. A token is displayed once when created, stored only as a hash, and can be revoked from project settings.

CI ingestion applies bounded body and test-count limits, request throttling, and idempotency checks. Evidence image uploads accept PNG, JPEG, GIF, and WebP only. TestDossier verifies both the declared media type and the file signature, hashes the full file for content-addressed storage, limits batch size, and enforces storage and rolling upload quotas. These checks are file validation, not malware scanning.

Optional CI source capture is bounded and redacted. It is off by default and reads only report-identified excerpts within a configured real, non-symlink repository root. The CLI skips symlinks, binary or invalid UTF-8 files, and files over 2 MiB; it caps each excerpt at 2,000 lines and 128 KiB and redacts common credential literals before upload. This redaction is a safety net, not a complete secret scanner. Source code is excluded from shared reports unless the owner separately opts in for that share.

Browser capture

The optional browser extension records only after you press Record and grant access to the site being tested. A session is buffered locally until you submit or discard it. Password fields and known secret-like form values are masked before they enter the buffer. File selections contribute only bounded, redacted base filenames to the test step—never file bytes or local paths. Page download/export controls may similarly contribute a bounded link-provided filename, but the extension has no permission to manage downloads and never reads downloaded bytes. Short visible status, validation, and heading text used in generated result prose is length-bounded and pattern-redacted. Cookies and authorization headers are not collected from observed browser traffic, and optional network previews are size-limited and redacted in the browser and again on submission.

Screenshots require your review. Before storing a screenshot, Capture makes a best-effort, capped attempt to mask detected sensitive-field regions. Detection or compositing can miss or fail, so masking is defense in depth, not a guarantee. Account names, customer data, open chats, or other visible content can still appear. Review every screenshot and use the manual black-out tool before submitting or sharing when needed. The detailed collection rules are in the Privacy Policy.

Browser and transport protections

Production traffic is redirected to HTTPS. Public and application responses use HTTP Strict Transport Security, an enforced Content Security Policy, clickjacking protection, MIME-sniffing protection, a restrictive browser permissions policy, and a referrer policy. The Content Security Policy blocks inline scripts; inline styles remain permitted for the current interface.

Retention, deletion, and recovery

Local authoring data remains in your browser until you remove it. Unimported Free capture bundles are assigned a seven-day expiry. Synced Pro data has a 30-day grace period after cancellation before it may be deleted. Account settings provide data export and account deletion; the cloud-backup ZIP includes evidence files as well as case records.

Deleting an account atomically removes personal database records and first records associated object-storage keys in a durable erasure queue. Erasure processing starts immediately, and the minutely retention worker retries bounded batches until complete. Workspace history remains with the workspace under an opaque erasure identity. Private recovery copies expire on a 35-day schedule. Keep your own current export for evidence your organization must retain independently.

Workspace owners and admins can export the whole workspace — every active test case in every project, with embedded evidence and a roster of members, roles, projects, and suites — as a sequence of re-importable ZIP parts, independently of any individual member's account.

Current assurance boundaries

TestDossier is in early access and is not currently SOC 2 or ISO 27001 certified. Passkeys, Google and Microsoft single sign-on, a per-workspace required sign-in method, and a per-workspace session-lifetime cap are available; SAML-based SSO, SCIM provisioning, customer-managed encryption keys, end-to-end encryption, and a customer-selectable data-residency commitment are not offered yet. Cloudflare's certifications cover its infrastructure and do not transfer to TestDossier. If one of these is a procurement requirement, contact us before adopting the service.

Your responsibilities

• Use MFA on the mailbox connected to your TestDossier account
• Add at least two passkeys on devices you control when practical, and remove a lost device under Account → Security
• Use test or synthetic data where possible, and do not place credentials or production secrets in steps, logs, or screenshots
• Treat report URLs and project access tokens as secrets; scope and revoke them when no longer needed
• Remove workspace members promptly when their access is no longer required
• Keep an independent export for evidence subject to your own retention obligations

Report a vulnerability

Please report suspected vulnerabilities privately to support@testdossier.com with the subject Security report. Include the affected URL or feature, reproduction steps, expected impact, and a safe way to contact you. Do not access data that is not yours, disrupt the service, or include live secrets in the report. TestDossier does not currently operate a paid bug-bounty program.

Related policies

For collection, subprocessors, retention, and data-rights details, read the Privacy Policy. For acceptable use, availability, and service terms, read the Terms of Service.