Security
Web Watch Tower watches other people's infrastructure, so its own has to be in order. This page describes, without marketing, what protects your account and your monitoring data, what we test ourselves, and how to report a vulnerability. Everything here is current as of the date at the bottom.
1.Account and access
Every account starts with a verified e-mail address: registration sends an activation link and nothing works before it is clicked. Passwords are never stored in a readable form, only as salted one-way hashes. Sign in with Google is optional and links to the same account by e-mail address.
Two-factor authentication comes in three independent forms: an authenticator app, a hardware security key and a passkey. They can be enabled together, and losing one does not lock you out of the others. Administrative access on our side always requires a second factor.
Settings > Sessions lists every signed-in device with its last activity; any session can be revoked from any other device. Login, password reset and registration are rate limited per address and protected against automated abuse.
2.Your data
The application and its database run in the European Union (Warsaw, Poland); transactional and alert e-mail leaves through an EU data centre; traffic terminates at Cloudflare over TLS only, and the .app domain is HSTS-preloaded, so browsers never try plain HTTP.
Notification channel secrets (webhook URLs, bot tokens, routing keys) are encrypted at rest and never returned in full by the API: they are redacted and visible to organisation owners only. Monitoring data belongs to one organisation; every API route is classified and the boundary between organisations is covered by automated tests.
You can export everything the service holds about your organisation as a ZIP from Settings > Account, leave an organisation, or delete your account yourself. Audit history survives a deletion in anonymised form, as the GDPR allows for accountability.
3.Application security
Every response carries a content security policy and the usual browser protections against framing, cross-origin leaks and referrer exposure. Requests the service makes on your behalf (webhooks, the checks themselves) pass a guard that refuses private and internal addresses. Every public endpoint has a per-address rate limit; hostile input is rejected before it reaches the application.
A security test program runs on request: every API route is listed in a matrix and swept anonymously, as a member, as an owner and as staff; hostile payloads hit every write route; the suite is mapped to the OWASP Top 10 and the OWASP API Top 10 and complemented by an automated scanner and a browser smoke test. Findings get a number, a severity and a decision, never a silent fix.
Dependencies and the runtime are kept current with a regular patch routine, and every round is recorded with the findings register.
4.Monitoring network
Checks run from our server in Poland and are confirmed by independent monitoring regions in Europe, North America, Asia and Oceania. Each region runs a small agent whose releases are cryptographically signed, so a region refuses an unsigned update; each region authenticates to the hub with its own credential bound to its address.
A region learns only the URL it is asked to check and reports the result; it holds no account data, no credentials and no notification secrets.
5.Operations
A single operator runs the service, which means short lines: production changes go out as reviewed, tested commits, secrets live outside the code, and logs are rotated and kept only briefly.
We publish our own status at /status and explain every availability figure on the methodology page: what we promise to measure for you, we measure for ourselves.
6.Reporting a vulnerability
If you believe you have found a security issue in Web Watch Tower, please tell us before telling anyone else. Write to the address in our security.txt or use the contact form, and include what you found, where, and how to reproduce it; a proof of concept helps, a working exploit is not necessary.
We read every report, confirm receipt, keep you informed while we fix the issue and, if you wish, credit you once it is resolved. We ask for reasonable time to fix before any publication. There is no paid bounty programme.
Rules for good-faith research: no denial of service or volume testing, no access to data that is not yours beyond the minimum needed to show the issue, no social engineering of our users or staff, and no changes to other people's monitors. Research that follows these rules will not be met with legal action.
Security contact
In scope
- webwatchtower.app and its API
- the monitoring agents and regions
- the public status pages and the directory
Out of scope
- third-party services we use (Cloudflare, Stripe, Google, Amazon SES, UpCloud, OVH)
- findings without a security impact: missing best-practice headers on static files, rate limits that merely exist, version disclosure
- clickjacking on pages without state-changing actions
Last changed: October 25, 2026
See also: Sub-processors · Privacy policy · Terms of service · How we measure availability