Skip to main content

Security model

Hook0 uses defense-in-depth with multiple layers of protection. This document covers the security architecture, threat model, and best practices.

Security architecture​

Multi-tenant isolation​

Organization boundaries​

  • Complete data isolation between organizations
  • Users can only access their organization's resources
  • Database queries filtered by organization_id
  • No cross-organization data leakage

Application scoping​

  • Events scoped to specific applications
  • Subscriptions tied to applications
  • Service tokens can be application-specific

API security​

Transport security​

  • TLS 1.2+ required for all API communication
  • HSTS headers enforce secure connections
  • Certificate pinning recommended for clients

Request validation​

// Input validation and sanitization
#[derive(Validate, Deserialize)]
struct EventPayload {
    #[validate(length(min = 1, max = 255))]
    event_type: String,
    
    #[validate(custom = "validate_json_size")]
    payload: Value,
}

Rate limiting​

  • Per-organization quotas
  • Per-IP rate limits
  • Adaptive rate limiting based on behavior
  • Protection against DoS attacks

Webhook security​

Signature verification​

All webhook deliveries include HMAC-SHA256 signatures in the X-Hook0-Signature header. Hook0 uses v1 signatures by default, which include selected headers for additional security:

X-Hook0-Signature: t=1765443663,h=content-type x-custom-header,v1=85da0586ae0b711d...
  • t: Unix timestamp (seconds)
  • h: Space-separated list of header names included in signature
  • v1: HMAC-SHA256 signature (hex-encoded)

Signature computation: HMAC-SHA256(secret, timestamp + "." + header_names + "." + header_values + "." + payload)

For implementation details and code examples in JavaScript, Python, and Go, see Implementing Webhook Authentication.

Target URL validation​

  • HTTPS required for production webhooks
  • Private IP ranges blocked by default
  • URL validation and sanitization
  • DNS rebinding protection: the address vetted by the IP check is pinned for the actual request, so the hostname cannot be re-resolved to a different IP between check and connect
  • Redirects are not followed: a target returning a 3xx cannot redirect the worker to an internal address

Note: if you configure an egress HTTP proxy for the output worker (HTTP_PROXY/HTTPS_PROXY/ALL_PROXY), the proxy performs its own DNS resolution and connection, which bypasses the target-IP guard and DNS pinning. Only point the worker at a proxy you trust.

Data protection​

Encryption at rest​

Hook0 Cloud application data is stored in a Clever Cloud managed PostgreSQL database and in object storage. This data is not encrypted at rest by default — Clever Cloud does not encrypt disk contents unless disk-level encryption is explicitly requested, and it is not currently enabled for Hook0 Cloud. If encryption at rest is a requirement for your organization, contact [email protected] to discuss dedicated deployment options.

These protections still apply regardless:

  • Passwords are hashed and never stored in a reversible form (see Password policy).
  • Subscription secrets are cryptographically random and are never logged or returned in API responses.
  • Access to the database and object storage is restricted, with access lists reviewed periodically (see Access control policy).

Encryption in transit​

  • TLS for all external communication
  • Internal service communication encrypted
  • Database connections encrypted

Data retention​

Webhook event data is retained per plan — Developer: 7 days, Startup: 14 days, Pro: 30 days, Enterprise: custom. Deletion is automatic:

  1. Once the retention window has elapsed, a 10-day grace period is applied.
  2. After the grace period, events and their related request attempts and responses are deleted from the database.
  3. Within 24 hours (at worst), the corresponding event and response payloads are deleted from object storage.

See the Information retention policy for the retention periods that apply to every other data type.

Secret management​

Subscription secrets​

  • Cryptographically random UUIDs
  • Never logged or exposed in responses
  • Rotatable through API
  • Scoped to individual subscriptions

Service tokens​

  • Long-lived tokens for API access
  • Restricted permissions
  • Audit logging for usage
  • Revocable at any time

Key rotation​

// Regular secret rotation
impl SubscriptionSecret {
    pub fn rotate(&mut self) -> Result<Uuid, Error> {
        let new_secret = Uuid::new_v4();
        self.previous_secret = Some(self.current_secret);
        self.current_secret = new_secret;
        Ok(new_secret)
    }
}

Threat model​

Identified threats​

T1: Unauthorized access​

  • Threat: Attackers gaining access to organization data
  • Mitigation: Strong authentication, authorization, audit logging

T2: Event injection​

  • Threat: Malicious events sent to trigger unwanted webhooks
  • Mitigation: Authentication, input validation, rate limiting

T3: Webhook tampering​

  • Threat: Attackers modifying webhook payloads in transit
  • Mitigation: HMAC signatures, TLS encryption

T4: Denial of service​

  • Threat: Service disruption through resource exhaustion
  • Mitigation: Rate limiting, quotas, circuit breakers

T5: Data exfiltration​

  • Threat: Sensitive data extracted from system
  • Mitigation: Access controls, audit logging, encryption

Attack vectors​

API endpoints​

  • Authentication bypass attempts
  • Authorization escalation
  • Input validation bypasses
  • Rate limit circumvention

Webhook targets​

  • Webhook replay attacks
  • Signature bypass attempts
  • Target URL manipulation
  • Response time analysis

Security best practices​

For Hook0 operators​

Infrastructure security​

# Kubernetes security context
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

Network security​

  • VPC isolation
  • Security groups/firewalls
  • Private subnets for databases
  • Network monitoring

Monitoring and alerting​

  • Failed authentication attempts
  • Unusual API usage patterns
  • High error rates
  • Resource exhaustion

For application developers​

Token management​

// Use environment variables for tokens
let token = env::var("HOOK0_TOKEN")
    .expect("HOOK0_TOKEN environment variable required");

// Do not log tokens
log::info!("Making API request with token: [REDACTED]");

Webhook verification​

See Implementing Webhook Authentication for signature verification code examples.

Error handling​

# Do not expose internal errors
try:
    process_webhook(payload)
except Exception as e:
    logger.error(f"Webhook processing failed: {e}")
    return {"error": "Internal server error"}, 500

For webhook recipients​

Endpoint security​

  • Use HTTPS with valid certificates
  • Implement signature verification
  • Validate payload structure
  • Rate limit webhook endpoints

Idempotency​

# Handle duplicate events
processed_events = set()

def handle_webhook(event_id, payload):
    if event_id in processed_events:
        return {"status": "already_processed"}
    
    result = process_event(payload)
    processed_events.add(event_id)
    return result

Compliance and standards​

Standards and frameworks​

  • GDPR: Hook0 is operated in compliance with the General Data Protection Regulation. See the Privacy policy and Information retention policy.
  • ISO 27001: our security practices align with the ISO 27001 framework and are managed through an information security management system (ISMS).

Hook0 runs on Clever Cloud, an infrastructure provider that maintains its own independent third-party security certifications.

Security headers​

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Content-Security-Policy: default-src 'self'

Audit logging​

{
  "timestamp": "2024-01-15T10:30:00Z",
  "user_id": "usr_123",
  "organization_id": "org_456", 
  "action": "subscription.created",
  "resource_id": "sub_789",
  "ip_address": "192.168.1.100",
  "user_agent": "Hook0-Client/1.0"
}

Security testing​

Automated testing​

  • Static code analysis (Clippy, security lints)
  • Dependency vulnerability scanning
  • Container image scanning
  • Infrastructure as code scanning

Penetration testing​

  • Regular third-party security assessments
  • API security testing
  • Webhook delivery security testing
  • Infrastructure penetration testing

Bug bounty program​

  • Responsible disclosure process
  • Security researcher rewards
  • Public security advisory process

Incident response​

Security incident handling​

  1. Detection: Automated alerts, monitoring
  2. Assessment: Impact and scope analysis
  3. Containment: Isolate affected systems
  4. Eradication: Remove vulnerabilities
  5. Recovery: Restore normal operations
  6. Lessons Learned: Process improvements

Communication plan​

  • Internal stakeholder notification
  • Customer communication
  • Public disclosure timeline
  • Regulatory reporting requirements

Next steps​