Skip to main content
npayload is launching soon.
npayloadDocs
Platform

Security

OAuth 2.0 + DPoP, three encryption modes, instance isolation, and compliance

Security is foundational to npayload. Every layer, from the edge to the instance, is designed with defence in depth.

Authentication

npayload uses OAuth 2.0 with DPoP (RFC 9449) for machine authentication. Unlike bearer tokens, DPoP tokens are bound to the client that requested them:

  • The client generates a key pair and signs a DPoP proof JWT for each request
  • The proof includes the HTTP method, URL, and a unique nonce
  • Even if a token is intercepted, it cannot be replayed from a different client

This prevents token theft, replay attacks, and man-in-the-middle attacks.

Encryption

npayload supports three privacy modes per channel:

ModeMetadataPayloadnpayload reads?Use case
StandardPlaintextPlaintextYesGeneral messaging, full feature set
HybridPlaintextEncryptedMetadata onlyRouting + filtering with payload privacy
E2EEncryptedEncryptedNoZero-knowledge, maximum privacy

Standard mode

All features available: payload-based filtering, schema validation, routing key matching, full-text search.

Hybrid mode

npayload can route and filter based on metadata (routing keys, timestamps, trace IDs) but cannot read the payload. Ideal for regulated data where you need routing but payload must be private.

E2E mode

Zero-knowledge encryption. npayload stores and delivers the payload without being able to read it. Only the publisher and subscriber hold decryption keys. Routing is limited to channel-level only.

E2E mode uses RSA-4096 for key exchange and AES-256-GCM for payload encryption.

Instance isolation

Each instance is a physically isolated deployment, dedicated or shared:

  • Separate database: Each instance has its own deployment with independent storage
  • Separate encryption keys: Keys are not shared between instances
  • Regional deployment: US-East, EU-West, AP-South. Data stays in the chosen region
  • No cross-tenant access: Row-level security (RLS) enforces tenant isolation within each instance

Network security

Edge layer

  • DDoS protection: Global edge network absorbs attacks before they reach backend services
  • TLS 1.3: All connections are encrypted in transit
  • No public IPs: Backend services are accessible only through outbound-only tunnels
  • WAF rules: Web Application Firewall blocks common attack patterns
  • Rate limiting: Per-IP and per-API-key rate limiting at the edge

Backend

  • Workload Identity: Services authenticate via identity federation with no static credentials
  • VPC isolation: Backend services run in private networks with no internet ingress
  • Secret management: All secrets stored in a managed secret store, never in environment variables or code
  • mTLS: Internal service-to-service communication uses mutual TLS

Security headers

Every API response includes security headers:

HeaderValue
Strict-Transport-Securitymax-age=31536000; includeSubDomains
X-Content-Type-Optionsnosniff
X-Frame-OptionsDENY
X-XSS-Protection1; mode=block

Audit trails

Every action in npayload is logged in an immutable audit trail with hash chain integrity:

  • Message publish, delivery, and retry events
  • Channel creation, update, and archive events
  • Subscription lifecycle events
  • Authentication and authorisation events
  • DLQ replay and purge events

Audit entries include a hash of the previous entry, forming a tamper-evident chain.

Compliance posture

StandardStatus
SOC 2 Type IIControls mapped, audit-ready
GDPRData residency via instance isolation, right to deletion
HIPAAE2E encryption, audit trails, access controls
ISO 27001Security management system aligned

SSRF protection

All outbound requests (webhook delivery, adapter calls) validate URLs against an allowlist:

  • No private IP ranges (10.x, 172.16-31.x, 192.168.x)
  • No localhost or loopback addresses
  • No non-HTTP(S) protocols
  • No port ranges in production

Next steps

Was this page helpful?

On this page