If you find a weakness in Spectate, we want to hear about it, so that we can fix it before anyone misuses it. This policy explains how to report a vulnerability, what we ask of you and what you can expect from us. It follows the Dutch guideline for Coordinated Vulnerability Disclosure of the National Cyber Security Centre (NCSC).

How to report

Email your report to security@spectate.net. Please include:

what the vulnerability is, and where (URL, endpoint, component or version);
the steps to reproduce it, with a proof of concept if you have one;
what an attacker could do with it, as far as you know;
your name or handle, if you want us to thank you, and how to reach you.

Write in English or Dutch. If your report contains sensitive details, ask us for a way to send them encrypted.

Our contact details for security are also in security.txt (RFC 9116).

Scope

In scope	What it covers
spectate.net	Our website
app.spectate.net	The dashboard
api.spectate.net	The API, including the endpoints for checkers, host agents, alert sources and integrations
*.spectate.page	Status pages we host, including the status page JSON API, feeds, subscriptions and private pages
Checker	The Spectate checker that runs uptime checks, including its protection against requests to private networks (SSRF)
Host agent	The Spectate host agent (github.com/spectate/agent) and its install script
Emails	The emails Spectate sends, such as alerts and status page updates, as far as they can be abused (for example HTML injection)

Out of scope	What it covers
Services of other companies	Vatly checkout and customer portal, Mollie, Lettermint, Bird, Slack, Discord, Microsoft Teams, Telegram, Pushover, Intercom, GitHub, Google, Microsoft and our hosting providers. Report problems there to the company itself
Customer-controlled content	The content of status pages, customer custom domains and their DNS records, and the systems our customers monitor
docs.spectate.net	Hosted by Mintlify. Report issues there, unless the issue affects the dashboard, API or customer data
Internal systems	Our back office and staff network, unless you found a way in from the internet

Issues we do not accept

These are not vulnerabilities for us, unless you show real impact:

denial-of-service or load-based attacks, and missing rate limits on endpoints without sensitive actions;
findings from automated scanners without a working proof;
missing security headers or cookie flags without a concrete way to exploit them;
clickjacking on status pages (customers may embed their status pages on purpose) or on pages without sensitive actions;
the public status page JSON API being readable by anyone (it is public by design, with Access-Control-Allow-Origin: *); private pages are in scope;
reports about SPF, DKIM, DMARC or DNSSEC configuration without a working attack;
self-XSS, logout CSRF, and attacks that need physical access to a device or an outdated browser;
disclosure of software versions or banners;
the fact that monitors can request any public URL, which is what monitoring does. Reaching private or internal addresses through a monitor, webhook or screenshot is in scope.

Rules

To stay within this policy, please:

do not run denial-of-service attacks, stress tests or high-volume automated scans, and do not create excessive numbers of accounts or monitors;
do not use social engineering (phishing, phone calls) against our staff or customers, and do not try physical attacks;
test only with accounts and Teams you created yourself. Do not access, change or delete data of other customers. If you get access to such data by accident, stop, do not keep a copy, and tell us in your report. Access only as much as you need to show the problem;
do not use the vulnerability further than needed to demonstrate it, for example do not install a backdoor, move to other systems or keep access;
do not use SMS or phone call features to call or text numbers that are not yours;
report the vulnerability to us as soon as possible after you found it, and only to us;
keep the vulnerability confidential until we have fixed it and agreed with you that it can be published.

What you can expect from us

Acknowledgement: we confirm that we received your report, usually within a few working days.
Assessment: we tell you whether we can reproduce it, how serious we think it is, and what we plan to do.
Fix: we fix serious vulnerabilities as soon as we can, and keep you informed of our progress.
Publication: once the vulnerability is fixed, we agree with you if, when and how it is published. If you want, we credit you by name.
Customers: if customer data was at risk, we inform the affected customers as our Data processing agreement requires.

Safe harbour

If you act in good faith and follow the rules in this policy, we will not take legal action against you and will not report you to the police for your research. We consider research under this policy to be authorised. If a third party takes legal action against you for research that followed this policy, we will make clear that you acted with our permission.

This does not apply if you clearly broke the rules, for example by accessing customer data beyond what was needed to show the problem, sharing the vulnerability with others or demanding money. Note that we cannot give permission for research on systems of other companies, such as our providers.

Rewards

We do not run a bug bounty programme and do not pay for reports. If you want, we credit you by name when the fix is published. Asking for payment in exchange for not publishing a vulnerability is not responsible disclosure.