Security
Last updated: April 28, 2026
Overview
Overview
This page explains how Pulsar protects authentication flows, APIs, database access, integrations and operational workflows. Controls are layered to reduce abuse, improve tenant isolation and strengthen recovery readiness.
Controls matrix
Key controls by layer, optimized for mobile scanning.
Identity and authentication
Controls: Email verification, optional TOTP MFA, org-level MFA enforcement, invite token validation
How: Credentials, verification state and MFA challenges are validated before sessions are issued.
When: Sign-up, sign-in and step-up flows.
Why: Reduce takeover risk and unauthorized access.
Session and browser protection
Controls: Signed HttpOnly JWT cookie, SameSite controls, same-origin checks, CSRF double-submit token
How: Authenticated requests validate session state. Mutating requests require origin and CSRF checks.
When: Every authenticated and state-changing request.
Why: Reduce token theft and cross-site request forgery.
API route protection
Controls: Central route guard, payload validation, rate limiting, workspace checks
How: Routes validate request structure and identity before business logic executes.
When: At API ingress.
Why: Stop malformed or abusive traffic early.
Authorization
Controls: Workspace membership checks and RBAC permission controls
How: Roles and membership are resolved server-side before protected operations run.
When: Before reads and writes.
Why: Ensure least-privilege access.
Database isolation
Controls: Workspace scoping, organization scoping, Supabase/Postgres RLS policies
How: Queries are tenant-scoped and reinforced at the database layer.
When: At query execution.
Why: Protect cross-tenant boundaries.
Secrets and credentials
Controls: AES-256-GCM encryption, hashed tokens, controlled reveal flows
How: Secrets are encrypted at rest and only decrypted in trusted server paths.
When: Storage and retrieval events.
Why: Protect sensitive integration material.
Webhook boundary
Controls: Provider signature checks, token gates, ingress rate limits, anti-replay nonce cache, optional IP allowlists, delivery persistence
How: Inbound callbacks validate signature or token before processing payloads. Request paths use dedicated rate limits, replay nonce checks on signed timestamped providers and optional source IP allowlists.
When: Immediately on webhook receipt and during delivery persistence.
Why: Reject spoofed traffic and improve forensic traceability.
Observability
Controls: Audit records, delivery logs, alert pathways
How: Sensitive actions emit logs and operational signals.
When: During and after critical events.
Why: Improve triage and recovery.
Lifecycle
1. Before access
Identity, invite requirements, credential validity and MFA requirements are checked before sessions are issued.
2. At request ingress
Protected routes enforce origin, CSRF and rate-limit checks before logic executes.
3. Before data operations
Workspace membership and RBAC permissions are resolved server-side.
4. At data access
Tenant-scoped queries and RLS policies reinforce isolation boundaries.
5. After changes
Operational and security-relevant events can emit logs, alerts and audit records.
Section
Pulsar routes use centralized guard patterns to combine authentication, request validation, same-origin checks and CSRF controls for mutating requests.
Protected APIs require valid workspace context before application logic touches business data.
Section
Operational data is scoped by workspace and organization boundaries.
Supabase/Postgres row-level security policies reinforce server-side controls.
Section
Integration secrets are encrypted with AES-256-GCM before storage.
One-time codes and token artifacts are stored as hashes where applicable.
Section
Inbound webhook routes enforce authenticity checks before processing provider payloads.
Provider-specific signature verification is used where supported (for example Slack, Calendly, Dropbox and HubSpot) and token gates are used on token-protected routes.
Webhook ingress uses route-level rate limits and optional source IP allowlists. Signed timestamped providers also pass replay/staleness checks before processing.
Delivery records are persisted to support replay analysis, debugging and incident triage.
Section
Critical actions emit audit and operational records used for accountability and recovery workflows.
Alert pathways reduce time-to-detect and time-to-triage.
Section
The controls above are active platform safeguards. The items below are prioritized next improvements to further reduce risk and tighten abuse resistance.
Reporting
To report a security concern, contact info@pulsarspaces.com with reproduction details, timestamps and any request IDs you captured.
For privacy and personal-data requests, contact privacy@pulsarspaces.com.
