Skip to content

Security Overview

MazeVault Security Architecture and Defense-in-Depth Strategy

Document Version: 1.0.0
Last Updated: 2026-10-28

1. Security Architecture

MazeVault implements a defense-in-depth security strategy with multiple protective layers:

graph TB
    subgraph L1["Layer 1: Network"]
        FW["🛡️ Firewall / NSG"]
        TLS["🔒 TLS 1.2+ Enforcement"]
        WAF["🌐 Web Application Firewall"]
    end

    subgraph L2["Layer 2: Application"]
        RL["⏱️ Rate Limiting"]
        CORS["🎯 CORS Validation"]
        CSRF["🛡️ CSRF Protection"]
        Input["✅ Input Validation"]
    end

    subgraph L3["Layer 3: Authentication"]
        MFA["🔐 Multi-Factor Auth"]
        SSO["🆔 SSO / SAML / OIDC"]
        SRP["🤝 SRP Protocol (API)"]
        JWT["🎫 Server-side Sessions / JWT"]
    end

    subgraph L4["Layer 4: Authorization"]
        RBAC["👥 Role-Based Access"]
        Project["📁 Project Isolation"]
        Perm["🔑 Granular Permissions"]
    end

    subgraph L5["Layer 5: Data"]
        AES["🔐 AES-256-GCM Encryption"]
        ZK["👁️‍🗨️ Client-Side Encryption (v2 data)"]
        HSM["🏦 HSM Key Protection"]
        Audit["📝 Audit Logging"]
    end

    L1 --> L2 --> L3 --> L4 --> L5

    classDef network fill:#F5F5F5,stroke:#9E9E9E,stroke-width:2px,color:#424242
    classDef app fill:#EBF5FB,stroke:#2196F3,stroke-width:2px,color:#1565C0
    classDef auth fill:#FFF8E1,stroke:#FF9800,stroke-width:2px,color:#E65100
    classDef authz fill:#E8F5E9,stroke:#4CAF50,stroke-width:2px,color:#2E7D32
    classDef data fill:#E8EAF6,stroke:#3F51B5,stroke-width:2px,color:#283593

    class FW,TLS,WAF network
    class RL,CORS,CSRF,Input app
    class MFA,SSO,SRP,JWT auth
    class RBAC,Project,Perm authz
    class AES,ZK,HSM,Audit data

2. Security Principles

Principle Implementation
Zero Trust All communication authenticated and encrypted; no implicit trust between components
Client-Side Encryption Secret names and values of v2 data can be encrypted in the browser with a key derived from the local password; this is not yet zero-knowledge (see Encryption)
Least Privilege RBAC with granular permissions; users access only what their role permits
Defense in Depth Five security layers — network, application, authentication, authorization, data
Secure by Default All security features enabled by default; opt-out rather than opt-in
Audit Everything Every data access and modification recorded with full user context

3. Transport Security

TLS Configuration

Parameter Value
Minimum TLS Version 1.2
Preferred TLS Version 1.3
Certificate Validation Required in production
HSTS Enabled (max-age=31536000, includeSubDomains)
Certificate Pinning Supported for agent-to-server communication

Security Headers

Every web interface response (pages, static assets, runtime config) includes the following security headers:

Header Value
X-Content-Type-Options nosniff
X-Frame-Options SAMEORIGIN
Strict-Transport-Security max-age=31536000; includeSubDomains (set by the web application)
Referrer-Policy strict-origin-when-cross-origin
Permissions-Policy Disables camera, microphone, geolocation, payment and USB; clipboard stays available
Cross-Origin-Opener-Policy same-origin
Cross-Origin-Resource-Policy same-origin
Content-Security-Policy Enforced, built per response; the inline scripts of the application are allowed by sha256- hash in script-src
Cross-Origin-Embedder-Policy require-corp (enforced)

The headers come from the web application itself, so they are identical behind the Compose edge and the Kubernetes ingress; the edge adds none. The /swagger pages are served by the API server and carry no application CSP. Static assets are served same-origin only, without Access-Control-Allow-Origin. A request for a file that does not exist returns 404 instead of the application page.

API responses are Cache-Control: no-store, no-cache, must-revalidate and X-Content-Type-Options: nosniff; only public resources such as CRLs set their own cache policy. The API also applies a Fetch Metadata resource isolation policy: a browser request from another site is rejected with 403 unless it is a top-level navigation (SSO callbacks, links), the SAML assertion POST, or comes from an origin in CORS_ALLOWED_ORIGINS. Agents, gateways, SCEP/ACME/OCSP clients and the CLI send no Fetch Metadata headers and are not affected.

4. Application Security

Rate Limiting

Endpoint Category Limit Window
Authentication 10 requests 1 minute
API (authenticated) 100 requests 1 minute
OCSP 1000 requests 1 minute
Health checks Unlimited —

Input Validation

  • All API inputs validated against JSON schemas
  • SQL injection prevention through parameterized queries
  • XSS prevention through output encoding and Content Security Policy
  • Path traversal prevention through input sanitization
  • Request body size limits enforced at ingress level

CORS Policy

  • Strict origin allowlisting (no wildcards in production)
  • Credentials mode requires explicit origin specification
  • Preflight caching for performance

Web Interface Server (BFF) Protections

  • The browser holds only the __Host-session cookie (Secure, HttpOnly, SameSite=Strict); no token is exposed to scripts
  • Every state-changing request must carry an Origin equal to the configured web interface address, otherwise 403
  • Only /api/v1/ and /api/v2/ paths are forwarded; sign-in and token routes are not reachable through the generic proxy, and encoded slashes and dot segments are refused
  • The server verifies the backend's TLS certificate and never disables the check
  • Request bodies, tokens and query strings are not logged

CSRF Protection

  • Web interface: origin check and SameSite=Strict session cookie (see above)
  • API clients: double-submit cookie pattern
  • SameSite=Lax on the CSRF and refresh token cookies
  • Custom header verification for API requests

5. Data Security Summary

Data Category Encryption at Rest Encryption in Transit Access Control
Secrets AES-256-GCM TLS 1.2+ RBAC + Project
Private Keys AES-256-GCM + HSM TLS 1.2+ RBAC + Project
Certificates Database-level TLS 1.2+ RBAC + Project
User Credentials bcrypt/Argon2 hash TLS 1.2+ Self + Admin
Session Tokens Only a hash is stored for web sessions TLS 1.2+ (Secure cookie) Self
Audit Logs Database-level TLS 1.2+ Admin only

6. Vulnerability Management

Practice Frequency Description
Dependency Scanning Continuous Automated scanning of all dependencies for known CVEs
Container Scanning Per build Docker image scanning with Trivy
Penetration Testing Annual Third-party security assessment
Code Review Per change Mandatory review for all security-relevant changes
Security Patching As needed Provider target release: Critical within 48 hours, High within 7 days (binding deadlines: see SLA)