Bugzio
Servers in the European Union
The application, the database and uploaded files run on Hetzner Online GmbH servers in Germany. Backups stay in the same jurisdiction.
Trust and compliance
Security
This page is for the person who asks, before anyone signs anything: where do our clients’ data end up? Every claim here is checkable — and the things we cannot claim yet are written just as plainly as the rest.
Servers in the EU — Germany
HTTPS for all traffic
Passwords hashed, never stored
Responsible disclosure
No payment card · Data in the EU · Unlimited reporters
Infrastructure
Where the data sits and how it travels
No copy of the data is kept outside the European Union, apart from the vendors named individually in the privacy policy.
HTTPS everywhere
The widget, the panel, the API and the public pages work over TLS only. An HTTP request is redirected to HTTPS, and HSTS tells the browser to go straight to HTTPS next time.
Cloudflare in front
CDN, DNS and protection against DDoS and bots. The TLS connection is terminated there. The visitor’s real IP address is restored on the server so that per-IP limits stay correct.
Response headers
What the application itself sends
These headers come from application code, not from one server’s config file. That is why the answer is identical in every environment — development, test and production.
| Header | Value | What it does |
|---|---|---|
| Content-Security-Policy | default-src 'self'; … | On the public pages, scripts, styles, fonts and images come from our own domain. A third-party origin is allowed for analytics alone — Google Analytics 4, which measures nothing until cookies are accepted and is documented in the cookie policy. Inline scripts are signed with a per-request nonce, and style-src carries no unsafe-inline — which is exactly why these pages contain no style attribute at all. The Value column shows the first directive; the full list comes back in the header itself. |
| X-Frame-Options | SAMEORIGIN | The page cannot be placed in someone else’s frame, so nobody can overlay a transparent layer and talk a visitor into clicking a button. The exceptions are the widget and public share links, which a customer embeds on purpose. |
| Permissions-Policy | camera=(), microphone=(), geolocation=(), payment=(), usb=() | The browser is denied the APIs the service does not need: camera, microphone, location, payments and USB. |
| X-Content-Type-Options | nosniff | The browser does not guess a file’s type from its content — an uploaded file cannot turn into an executable script. |
| Referrer-Policy | strict-origin-when-cross-origin | Only the domain is passed to an external site, never the full URL with its parameters. |
| Cross-Origin-Opener-Policy | same-origin | Public pages are isolated in the browser process from the windows that opened them. |
| Strict-Transport-Security | max-age | Comes from Cloudflare, not from application code. That is deliberate: setting includeSubDomains from code could lock out a subdomain that is not HTTPS-only yet. |
Check it yourself: open any page on this site with your browser’s developer tools and read the response headers. That is exactly what our security scanner does on customer sites.
Accounts and access
Who gets into the panel
Six things that are implemented, not promised.
Data
What the widget collects — and what it does not
The content of a report belongs to you; we are the processor. Here is the exact list of what ends up in one.
Included in a report Collected
- The title, description and email the reporter types in, if they give one.
- The screenshot exactly as the reporter leaves it — with arrows, highlights and blurred fields.
- Browser console logs and uncaught JavaScript errors with their stack trace.
- Failed network requests: method, address, status code and duration.
- Page URL, browser and version, operating system, screen and window size, time zone and language.
- Screen video and a voice note, when the reporter records them — recording starts only after they confirm it, and only where the plan allows it.
- Session replay: roughly the last 20 seconds of page events before the report, when the feature is switched on for the project.
By default at most the last 120 diagnostic entries are kept — exactly as much as reproducing the bug needs.
Not included in a report Not collected
- The bodies of network requests and responses. Only metadata is kept — what was called and with what result.
- Cookies, local storage and authorisation tokens are never read or sent.
- The raw, un-blurred screenshot. Only the image the reporter saw and approved reaches the server.
- An honest warning: console logs are stored as they are. If your page prints sensitive data to the console, it will land in the report — worth checking before you switch the widget on.
The number of diagnostic entries kept can be lowered with the widget’s data-diagnostics-limit setting.
The blur tool
Before sending, the reporter can blur any part of the screenshot — a client’s name, an invoice total, a personal ID. The blurring happens in the browser, on the image itself, before it is uploaded: the original never leaves the device. The area is pixelated first and then softened, so even small text cannot be read back.
Retention
How long the data is kept
Retention is part of the plan and is applied automatically. The numbers come from the same plan catalogue the application itself runs on.
| Plan | Bug report retention | Monitoring history |
|---|---|---|
| Solo | 90 days | 30 days |
| Starter | 12 months | 30 days |
| Studio | Unlimited | 12 months |
| Agency · Enterprise | Unlimited | Unlimited |
Sub-processors
The full list — which vendor, for what purpose and in which jurisdiction — is in the privacy policy. We keep it in one place on purpose: two lists start to diverge sooner or later, and that is exactly what an audit spots.
Found a vulnerability?
Write to [email protected]. We confirm receipt, investigate, and tell you when the fix has shipped.
Please do not publish details until a fix is ready, and do not test in ways that could affect other customers’ data or the availability of the service. We do not run a paid bounty programme yet.
Honestly
What we cannot claim yet
This section exists because a vague phrase in a procurement questionnaire costs more than a clear “not yet”. If any of this is a hard requirement for you, better to find out now than three meetings from now.
No SOC 2 certification
We hold neither a SOC 2 Type I nor a Type II report, and we have never been through that audit. If it is a procurement requirement for you, we do not meet it today.
No ISO 27001
There is no certificate, and we do not claim to be “ISO 27001 aligned”. Without a certificate that phrase means nothing.
No independent penetration test
We offer no public pentest report. Our own security scanner also checks our site, but that is not an independent audit and we do not call it one.
No two-factor authentication
The panel is password-only for now. Two-factor login is on the plan, but until it exists we do not put it on a feature list.
No downtime penalty
The availability target, and the promise to announce planned work at least 24 hours ahead, are written into the terms; a compensation mechanism exists only in an individual Enterprise contract. We do not offer a publicly measured SLA with penalties.
No choice of data region
Every customer sits on the same EU infrastructure in Germany. Choosing another region or a dedicated instance is not possible today.
Legal
Documents
The legal part in full — the same thing your lawyer will ask for as a contract annex.
Need a security questionnaire filled in?
Send us your questionnaire or list of questions. We answer with the same honesty this page has — and where the answer is no, we write no.
Security matters: [email protected]