Security
How Zyre is built, and what it cannot see
You hand us your site's traffic. This page describes what happens between the visitor and your server, what we keep, what we do not keep — and what we cannot do.
The architecture, in one sentence
Zyre is a reverse proxy. Your domain points at our servers; every request is inspected there before being relayed to your server, which we call the origin. No code runs on your side, and we have no access to your server, your files or your database.
visitor → TLS → web application firewall → your origin
What we keep — and what we do not
Never kept
- Request bodies. A login form blocked by mistake would archive the password inside it: the offending field is named, its content never is.
- The Cookie and Authorization headers, excluded from capture by a positive allowlist.
- The content of your pages. We relay, we do not store.
Kept, and why
- The metadata of a blocked request: timestamp, method, path, source IP address, rule fired, incident identifier. Without them, a block cannot be explained.
- Traffic counters aggregated by hour, for charts and anomaly detection.
- The results of availability probes.
Retention depends on your plan and is shown in your dashboard. Export and deletion are self-service.
Hosting and personal data
Application data is hosted in Switzerland, with Infomaniak Network SA (Geneva) — a country recognised by the European Commission as offering an adequate level of protection. Transport is encrypted with TLS, storage is encrypted at rest at the infrastructure level. A data processing agreement compliant with Article 28 GDPR is published, without having to ask for it.
Sources
Your account's security
- Second factor via authenticator app (TOTP) or e-mail. The enrolment QR code is encoded by us and passes through no third party.
- Session held in a signed cookie, HttpOnly and Secure, with CSRF protection on every mutation.
- Password policy with a denylist of forbidden passwords, and an alert sent to the account holder on repeated attempts.
- E-mail address changes in two steps, with a warning sent to the OLD address before anything changes — the only channel that still reaches the holder if their session has been stolen.
- Scoped teams: a member can be restricted to certain sites, and that restriction applies to data as much as to settings.
What we cannot do
A security page that lists only guarantees informs nobody. These are the limits we accept, written here rather than discovered during an incident.
- We do not protect against a volumetric network-level attack. If your link is saturated, packets are lost upstream and no application filter runs at all.
- We do not read your server. A modified file, an admin account created on your side, a backdoor dropped through another path: we do not see them.
- A request body declared binary is not inspected. It reaches your origin as a file, not as a form value.
- TLS termination and routing currently run on single-site infrastructure. We do not sell multi-region high availability, and we do not imply it.
Reporting a vulnerability
If you believe you have found a flaw in Zyre, write to us. We acknowledge, we answer, and we do not pursue anyone for research carried out in good faith and without degrading the service.
Write to usYour site will be attacked.
The only question is whether you'll be ready.
Join the companies that chose to stop taking the hit.
Set up in 10 minutes · Cancel anytime · Hosted in Switzerland
ZyreEnterprise-grade SaaS protection for your sites and infrastructure.
© 2026 Zyre · All rights reserved