Security
CSRF, cookies, SSRF guard, refresh-token reuse, hardening headers, audit log.
Double-submit cookie pattern. pulse_csrf is set on first request, must be echoed in the X-CSRF-Token header on any non-GET. SPA’s api() helper does this automatically; API consumers need to handle it.
Cookies
Section titled “Cookies”pulse_session is HttpOnly, Secure, SameSite=Lax. Refresh tokens never live in JS-readable storage.
SSRF guard
Section titled “SSRF guard”HTTP monitors reject targets that resolve to:
- RFC1918 private space (
10/8,172.16/12,192.168/16) - Loopback (
127/8) - Cloud metadata endpoints (
169.254.169.254, IMDSv2 too) - IPv6 ULA (
fc00::/7) and link-local (fe80::/10) 0.0.0.0/8and other reserved ranges
DNS rebinding is mitigated by re-resolving immediately before connect (TOCTOU window kept tight).
Refresh-token reuse
Section titled “Refresh-token reuse”A refresh token can be used exactly once. The token’s family (linked rotations) is revoked on detected reuse. This catches the case where an attacker steals a refresh token, uses it, then the legitimate browser tries to use it later — both get bounced to /login.
Headers
Section titled “Headers”Standard hardening: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin. No Content-Security-Policy yet — it’s the right thing but inline styles in the no-JS status-page template currently prevent a tight CSP without unsafe-inline. Tracked.
Audit log
Section titled “Audit log”Settings → Audit log lists significant org actions: monitor create/edit/delete, alert rule changes, member invites/role changes, channel changes, status-page changes, incident actions. Retained 90 days. Useful for compliance and “who paused that monitor at 3am” forensics.