Security at PingStuff

How we check your site, honestly

PingStuff checks your site over http and https — the same way a browser reaches it — from our own servers, outside your network. Today those checks run from a single vantage point; confirming an outage from several regions at once is rolling out but is not live yet. We do not make uptime guarantees, and we tell you when a result is uncertain rather than fake a verdict.

Passwordless sign-in

There are no passwords to steal, because we never set any. You sign in with a one-time magic link sent to your email, and your session lives in an httpOnly, secure cookie. That removes a whole class of risk — reused passwords, credential-stuffing, leaked password hashes — from the product entirely.

The checker cannot be pointed at private systems

A tool that fetches any URL you hand it is a classic way to reach systems that were never meant to be public. Every check — and every redirect it follows — runs through a guard that resolves the target, refuses private, reserved and cloud-metadata addresses, and pins the one vetted address so it cannot be swapped out mid-request. Anonymous checks are limited to ports 80 and 443. This guard is the most heavily tested part of our codebase.

Your account is separated from everyone else’s

Every query for your data is scoped to your organization from your signed-in session, never from anything the browser claims. That boundary is covered by an automated cross-tenant test matrix that runs on every change, so a regression that could leak one account’s data into another fails the build before it ships. We have also staged database-level row isolation as defense-in-depth; it is built but is not yet the enforcing layer in production, so we do not claim it as one.

Shared report links are safe to share — and to take back

When you share an incident report, we generate a long random link and store only a hash of it, so the raw token is never sitting in our database. Shared reports are marked so search engines skip them, and you stay in control of each link:

• Revoke it at any time, or regenerate a fresh one.
• Expire it automatically after a window you choose.
• Protect it with a passcode; attempts are rate-limited and fail closed.
• Redact the technical detail before you send it.
• See an access log of when the link was opened.

Webhooks are verified, not trusted

Incoming webhooks — for example from a payment or SMS provider — are checked against a signature computed over the raw request body before we act on them, and we record the event IDs we have already processed so a replay or duplicate delivery cannot double-fire.

Data and backups

The database is backed up nightly, and we have rehearsed a full restore from those backups — downloading an off-site copy, decrypting it and confirming it restores — so we know they actually work rather than just that they exist. Each nightly backup is encrypted on the server before it leaves, then copied to storage at a different provider in a different location, where it is kept for 30 days. The key needed to decrypt those off-site copies is not stored on the server.

To be precise about scope: the working copies that stay on the app server itself — the most recent 14 days — are not encrypted at rest. Anyone who compromised that server would already have the live database, so this does not widen the blast radius, but we would rather state it than imply otherwise.

Transport and browser headers

Everything is served over HTTPS with automatically-renewed certificates, and plain http is redirected up to https. We send HSTS with preload so browsers refuse to talk to us over an insecure connection, X-Content-Type-Options: nosniff to stop content-type guessing, and a strict Referrer-Policy of strict-origin-when-cross-origin. We also suppress the framework’s X-Powered-By header.

On top of those, a Content-Security-Policy restricts where the page may load scripts, styles, images and frames from — same-origin, with no cross-origin script loading — which limits what an injected script could do. X-Frame-Options: DENY and a frame-ancestors ’none’ directive stop the site being framed for clickjacking, a Permissions-Policy switches off browser features we never use (camera, microphone, geolocation and the like), and Cross-Origin-Opener-Policy isolates our browsing context. We name exactly what we send rather than imply a longer list.

Who else touches your data

Running PingStuff means relying on a handful of third-party providers — for hosting, email, SMS and the like. We keep the current list, and what each one is used for, on our subprocessors page.

What we do not claim

We are not going to overstate this. PingStuff holds no security certifications — no SOC 2, no ISO 27001, no PCI attestation — and this page is a description of our engineering practices, not an audit or a compliance statement. Checks run from a single vantage point today. If a control is not listed on this page, please assume we have not built it yet.