Security and Trust for PageLantern

1. Security Program and Shared Responsibility

This page describes the security practices of the hosted PageLantern service — the website, customer portal, monitoring API, probe workers, notification delivery, and public status pages — as they exist today. It is written to be accurate rather than aspirational. It is not a certification, warranty, or guarantee.

No method of transmission over the internet, and no method of electronic storage, is completely secure. The measures below are designed to reduce risk; we cannot and do not guarantee absolute security. Certain controls are noted where they depend on how a deployment is configured, and our practices may change as the service evolves.

Security is a shared responsibility. We are responsible for the safeguards described on this page. You are responsible for safeguarding your account credentials, enabling available protections such as multi-factor authentication, scoping and rotating API keys, configuring only the targets and recipients you are authorized to monitor and contact, and treating heartbeat URLs as bearer secrets — they are the one credential-bearing field we cannot encrypt at rest, for the reason given under Data Protection and Encryption.

2. Account and Authentication Security

PageLantern is built around authenticated users, organization membership, and role-aware access to monitoring data. Accounts are protected by the measures below.

• Account passwords are never stored in clear text. We store them only as salted, iterated cryptographic hashes (PBKDF2-HMAC-SHA256 with 600,000 iterations and a unique 128-bit random salt per password), and verify them using a constant-time comparison.
• Server-side session records store only a SHA-256 hash of the session token, never the raw token. Sessions carry expiry and revocation timestamps and are validated on every request, and a successful password reset revokes that user's existing sessions.
• Session tokens are signed with HMAC-SHA256 and verified using a constant-time comparison. By default, a startup hardening check refuses to start a non-loopback (production) deployment that still uses a default development signing secret or a secret shorter than 32 characters; this check can be explicitly disabled for local or development environments through an opt-in flag that is off by default.
• When session transport uses a cookie, the cookie is set HttpOnly and SameSite=Lax, with the Secure attribute applied in production. The API also accepts the session token through an Authorization: Bearer header.
• API keys are generated from a cryptographically secure random number generator, shown only once at creation, and stored only as a SHA-256 hash alongside a non-secret prefix. Each key carries scopes, a last-used timestamp, and an expiry (90 days by default, 365 days maximum), and can be revoked; expired or revoked keys are rejected.
• Authentication-sensitive endpoints — sign-in, registration, password-reset request and confirmation, email verification, social sign-in, multi-factor challenges, and heartbeat ingestion — are throttled with per-IP and per-account limits and lockouts. This throttling is aimed at authentication abuse; it is not a general-purpose or volumetric denial-of-service defense.

3. Multi-Factor Authentication

PageLantern supports multiple second factors. Where a factor stores a secret or a destination, that value is encrypted at rest.

• Time-based one-time password (TOTP) seeds are encrypted at rest with AES-256-GCM, and a submitted code is accepted only within a one-step (approximately 90-second) window.
• SMS and email one-time codes are stored only as SHA-256 hashes, expire after 10 minutes, and are checked in constant time. The underlying SMS and email destinations are encrypted at rest with AES-256-GCM and shown only in masked form.
• Passkeys (WebAuthn) are supported. On sign-in, the server verifies the relying-party identifier, the user-presence and (by default) user-verification flags, the challenge, an allow-listed origin, and the assertion signature, and enforces signature-counter monotonicity to help detect cloned authenticators.
• Recovery codes are generated from a cryptographically secure random number generator, stored only as hashes, shown once, and usable only once.

4. Monitoring and Probe Safety

Because PageLantern reaches the targets that customers specify, it applies controls intended to keep probing from being misused to reach internal infrastructure.

• By default, probes refuse requests that resolve to private, loopback, link-local, carrier-grade-NAT, multicast, or IPv4-mapped IPv6 addresses, and block known cloud-metadata endpoints; only the HTTP and HTTPS schemes are permitted. The guard resolves DNS and validates the resolved address before connecting. These restrictions can be deliberately relaxed by an operator for an appropriate private environment, and they are a security measure rather than a guarantee.
• Redirects are followed a bounded number of times (at most five), and each redirect target is re-validated against the same network restrictions before the next request. Responses are bounded by a configurable size cap, header and line limits, and a request timeout.
• Customers are responsible for configuring only targets they own, control, or are authorized to monitor.

5. Data Protection and Encryption

Connections to the PageLantern web application and API are served over HTTPS/TLS, and the web interface is delivered with HTTP security headers, including a restrictive Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a Referrer-Policy, a Permissions-Policy, and HTTP Strict Transport Security on HTTPS connections.

We encrypt every credential-bearing field at rest with AES-256-GCM, on every plan, under a versioned envelope that permits key rotation and dual-reads older records during a rotation. That covers API authentication-profile secrets, multi-factor authentication secrets and destinations, notification-channel destinations, and the monitor-configuration fields customers fill in: request header values, request bodies, environment variables, API step definitions, browser scripts, and alert webhook URLs. A masked copy is kept for display, and sensitive values are additionally masked by field name in logs, stored diagnostic captures, and API responses.

Encryption at rest is not a plan feature and is never withheld from a tier. It is applied at the persistence layer to every account.

Two things are deliberately not encrypted, and we would rather say so than let you assume otherwise. Heartbeat tokens are stored in clear text because an inbound ping is authenticated by matching the token value it presents, which requires the stored value to be readable — treat a heartbeat URL as a bearer secret, keep it out of public repositories, and rotate it if it may have leaked. Public status-page subscriber email addresses are stored in clear text within the status page's records. Probe results, response-body excerpts and incident text are also stored without field-level encryption.

We do not provide transparent, database-wide encryption at rest.

Production deployments are expected to use private networking, least-privilege database credentials, and backups; some of these protections depend on deployment configuration as described under Configuration and Deployment Hardening.

6. Logging, Access Control, and Tenant Isolation

Access to monitoring data is mediated by server-side authorization, organization scoping, and an audit trail.

• An audit trail records the acting user, the resolved client IP address, the user-agent, the event type, and event details, scoped to each organization, and is retained for approximately 365 days by default. Client-IP resolution trusts forwarded headers only from explicitly configured trusted proxies and otherwise uses the direct connection address. These audit records are not represented as tamper-evident or cryptographically signed.
• API endpoints require an authenticated session by default, and sensitive or mutating operations are restricted to organization owners and administrators by a server-side authorization filter. Resources are scoped to the caller's organization, and public status pages serve only the pages that have been explicitly marked public.
• Cross-origin browser access is governed by a default-deny allow-list of permitted origins; a cross-origin request presenting an origin that is not on the list is rejected. Cross-site request forgery exposure on the session cookie is reduced by SameSite=Lax cookies and this origin allow-list. We do not use dedicated CSRF tokens, and this protection does not fully cover top-level navigations.
• The internal metrics endpoint is closed by default and requires a separately configured access token.

7. Configuration and Deployment Hardening

Several of the protections described here are enforced when the service starts. A startup hardening check is designed to prevent a production deployment from booting with default development secrets, an over-permissive cross-origin configuration, or other unsafe defaults, and to surface warnings for configuration that is risky but not fatal.

The exact configuration of any given deployment may vary, and certain protections are configuration-dependent as noted throughout this page.

8. Third Parties That Process Data For Us

We keep this list short on purpose, and we name providers rather than describing categories. The authoritative, current list — with each provider's purpose, the personal data involved, and its region where known — is published at pagelantern.com/subprocessors, and we give account owners at least 30 days' notice before a new sub-processor begins processing.

• Mailgun delivers transactional, alert and status-page email. Recipient addresses and message content pass through it.
• Twilio delivers SMS alerts on paid plans and SMS one-time codes where SMS multi-factor authentication is enabled. It receives the recipient number and the message content.
• Stripe processes checkout, payment methods, subscriptions, invoices and refunds. No full card number is processed inside PageLantern.
• Google, Apple, Microsoft and Facebook process identity assertions when a user chooses to sign in with them. Google Identity Services may offer an account-selection prompt on the public homepage, but PageLantern receives the assertion only after the user chooses to continue.
• Google Analytics 4 measures website and application usage. The tag ships with consent defaults set to denied, so it writes no analytics cookie and reads no device identifier until a visitor accepts. Advertising features and ad-purpose data sharing are not enabled.
• An optional S3-compatible object store holds browser-check artifacts (screenshots, HAR captures, console logs) where it is configured; by default those artifacts stay on the operator's own filesystem. Artifacts are retained for approximately 14 days.
• Logging and observability run on a self-hosted stack operated by us, not a third-party SaaS. Application logs include client IP addresses and masked request paths.

9. Certifications and Independent Audits

PageLantern is an independent product and has not obtained SOC 2, ISO 27001, HIPAA, PCI DSS, FedRAMP, or similar certifications, and the statements on this page have not been independently audited or certified by a third party. We do not display compliance seals or badges.

PageLantern should not be represented as SOC 2, ISO 27001, HIPAA, PCI DSS, FedRAMP, or government-certified unless a separate written agreement says so. We secure the service platform; customers remain responsible for their monitored targets, the credentials and payloads they configure, the recipients they contact, their own legal authority and compliance, and the security of their access devices and accounts.

10. Incident Response and Breach Notification

If we become aware of a security incident affecting customer data, we will investigate promptly, take reasonable steps to contain and remediate it, and notify affected customers without undue delay in accordance with our agreements and applicable law.

For the monitoring content that customers configure, PageLantern generally acts as a service provider (processor) on the customer's behalf. In that role, our breach-notification obligation runs to the customer; notifications to regulators or to affected individuals, where required by law, are the responsibility of the customer as the controller of that content. This mirrors the roles described in our Privacy Notice.

11. Service Limitations and No Safety-Critical Reliance

Monitoring results, status codes, response times, certificate and DNS data, screenshots, and diagnostics are provided for informational and operational purposes only. They may be delayed, incomplete, or inaccurate and are not a guarantee of a target's actual availability, security, or correctness.

PageLantern is a monitoring and alerting tool. It is not a fail-safe, high-availability, or emergency-response system, and it must not be relied upon as the sole control for emergency, life-safety, or other safety-critical decisions. You remain responsible for independent checks, backups, and your own incident response.