Security

A bug report can contain what your users see and type. That is why protection starts in their browser, before anything is sent.

#In the browser: mask before sending

• Nothing is uploaded until the person submits the report. In the meantime, the replay, console and network live only in the tab's memory (about 2 minutes) and are continuously discarded. The exception is auto-capture in "automatic" mode, which the customer must explicitly enable and which has strict per-session limits.
• Forms and passwords masked by default in the replay and in the screenshot. Passwords, always.
• Sensitive headers replaced: Authorization, Cookie, Set-Cookie, X-Api-Key, CSRF tokens and others.
• Sensitive keys in JSON, forms and URLs (password, token, secret, api_key, session, card, cvv…) replaced with [REDACTED].
• Detection in free text of JWTs, Bearer/Basic credentials, Stripe, GitHub, Slack and AWS keys, and valid card numbers (Luhn).
• Customers can hide entire elements, add their own rules and review or discard each report with beforeSend.
• The widget lives in an isolated Shadow DOM and does not install cookies.

Technical details at Privacy and masking.

#In transit

• All communication uses HTTPS (TLS).
• The SDK uploads the report files directly to storage with signed URLs that expire in 10 minutes and have the exact size signed: they cannot be reused or used to upload anything else.
• The API only accepts reports from each project's allowed origins.

#At rest

• Database and files hosted on Neon (Postgres and object storage) on AWS us-east-2, encrypted at rest by the provider.
• Integration credentials (OAuth tokens, API keys, webhook secrets) encrypted at the application level with AES-256-GCM. They are never sent to the browser.
• API/MCP tokens (wbt_…) and project secret keys (sk_…): we only store their SHA-256 hash. They are shown once when created and can be revoked or regenerated.
• Passwords managed by Neon's authentication service, which stores only a hash.
• Row-level security (RLS) enabled on all tables, with no public access policies: no data is accessible through a direct data API. Only Wutbug's servers connect to the database.

#Access control

• Each report belongs to a project and each project to a team. Access is verified on every request against current membership: if someone leaves the team, they lose access immediately, including on their MCP tokens.
• Roles owner, admin and member: only owners and admins configure projects, integrations and people. See Team and roles.
• Share links for a report and the reporter's page use long random tokens, do not appear in search engines and can be disabled. The reporter's page shows only their description and the public conversation, never the replay, console, network or internal notes.
• Incoming webhooks from integrations are verified with an HMAC or JWT signature.

#Abuse protection

Rate limits per IP and per project, quotas per plan, duplicate report detection, a limit on pending uploads and IP and origin blocklists. IPs are used only in temporary counters and are not stored in reports. See Retention and limits.

#Retention and deletion

• Retention configurable per project (7 to 365 days; 30 by default). An automated process deletes expired reports: first the files, then the records.
• Incomplete uploads deleted after 1 hour.
• Deleting a team deletes all of its projects, reports, recordings and integrations.

#Artificial intelligence

The summary of each report is generated on the server through OpenRouter with a low-cost model, using the data already masked, and routed only to providers that do not store prompts or train on them. We do not use reports to train models.

#Incidents

If an incident affecting personal data occurs, we will notify the affected customers without undue delay and within 48 hours of our confirming it, in accordance with the DPA.

#Reporting a vulnerability

Write to us at [Security email] with the details. We respond within [N] business days and will not take legal action against good-faith research that respects users' privacy and does not affect the Service.