Security and responsible disclosure

How the service is protected

• Passwords and tokens. Passwords are stored as salted hashes. Session tokens and API keys are stored as hashes, so a database read does not reveal a usable credential.
• Sessions. The sign-in cookie is HttpOnly and SameSite=Lax, a fresh token is issued on every sign-in, and sessions are revoked when you change your password or delete your account. You can review and revoke sessions in Settings.
• Organization isolation. Every request to read or change monitors, incidents, status pages, notification channels and settings is authorized on the server against your organization. Identifiers alone never grant access.
• Request forgery. State-changing API requests from another origin are rejected before they reach application code.
• Rate limiting. Sign-up, sign-in, password reset, account deletion and the free checker are rate limited.
• Secrets. Webhook signing secrets are encrypted at rest, and webhook calls can be signed so you can verify them. Credentials are never written to logs.
• Transport and headers. The site is served over HTTPS in production with HTTP Strict Transport Security, and sends headers that prevent framing and content-type sniffing.
• Reliable state. Incident and notification state is stored in the database, so alerts are tracked, retried on temporary failure and not duplicated.

Protecting the sites you monitor

Outbound requests are a risk in any service that fetches URLs on behalf of users. Before every check, the destination is resolved and validated, private, loopback, link-local and cloud-metadata addresses are refused, redirects are validated at each step, and the connection is made to the address that was validated. Responses are limited in size and time. The same checks apply to the free uptime checker. See the Acceptable Use Policy.

Your part

• Use a long, unique password and keep API keys secret. Revoke any key you no longer use.
• Treat webhook endpoints like any public endpoint: verify the signature and use HTTPS.
• Anything you publish on a public status page can be read by anyone with the link.

Report a vulnerability

If you believe you have found a security vulnerability in Website Monitor, please tell us privately at (this deployment has not configured a contact address yet).

Please include

• What the issue is and which page, endpoint or feature is affected.
• Steps to reproduce it, or a short proof of concept.
• What an attacker could achieve, in your assessment.
• Any logs or screenshots, and how you would like to be credited, if at all.

Please do not

• Access, change or delete data that is not yours, or keep data you encounter. Stop and tell us.
• Disrupt the service with denial-of-service, load testing or high-volume automated scanning.
• Use social engineering, phishing or physical attacks against anyone.
• Test against the monitored websites of other people, or use the service to attack third parties.
• Publish details before we have had a reasonable chance to fix the issue.

Scope and rules

In scope: this website and the Website Monitor application and API. Out of scope: third-party services we rely on (report those to their owners), findings with no demonstrable security impact such as missing best-practice headers on its own, and attacks that need an already-compromised device or account. Research that follows these rules and is carried out in good faith will be treated as authorized.

What happens next

We will acknowledge your report, look into it, tell you what we find, and fix valid issues. We will ask before crediting you publicly. We cannot promise a fixed timeline for every report, but we will keep you informed.

Certifications

We do not publish compliance certifications on this site, and nothing here should be read as claiming one. If you need a security questionnaire answered for procurement, contact us.