Skip to main content
Security is the foundation of DECODA’s architecture. Every design decision prioritises safe handling of malicious files and protection of user data.

​
Sandbox Isolation

Every analysis runs inside an isolated Firecracker microVM powered by E2B. Each sandbox is:
  • Fresh — A new VM is created for every analysis session. No data persists between sessions.
  • Network-disabled — No outbound or inbound network access. Malware cannot phone home, download payloads, or exfiltrate data.
  • Non-root — Analysis runs as an unprivileged user inside the VM.
  • Time-limited — Tools have strict timeouts (60-180 seconds depending on the tool).
  • Concurrency-limited — Maximum 10 simultaneous sandboxes to prevent resource exhaustion.

​
Command Blocking

The sandbox blocks dangerous shell commands:
  • rm -rf / and variants
  • curl | sh, wget | sh (download-and-execute)
  • nc, netcat (network tools)
  • sudo, su (privilege escalation)
  • chmod 777 (permission weakening)

​
Python Module Blocking

Python scripts cannot import modules that would break isolation:
  • subprocess — No shell command execution from Python
  • socket — No network access
  • requests, urllib — No HTTP clients
  • ctypes — No foreign function interface
These restrictions exist to prevent malware analysis tools from being abused as an execution environment. All analysis is static — DECODA does not execute malware samples.

​
Data Protection

​
File Storage

  • Uploaded samples are stored securely and associated with your account
  • Samples are deduplicated by SHA256 hash within your account
  • File size limits are enforced per tier (10-100 MB)

​
File Validation

Before any processing, uploads are validated for:
  • Path traversal — Filenames are sanitised to prevent directory escape attacks
  • Zip bomb detection — Archives are checked for decompression bombs before extraction
  • Size limits — Enforced before and after extraction

​
Encryption

  • VirusTotal API keys — Encrypted with AES-256-GCM before storage
  • All traffic — HTTPS/TLS in transit
  • Security headers — All API responses include X-Content-Type-Options: nosniff, X-Frame-Options: DENY, HSTS, and Cache-Control: no-store

​
Authentication & Access Control

​
Authentication

DECODA uses WorkOS AuthKit for authentication, supporting:
  • OAuth (Google, GitHub, Microsoft)
  • SAML SSO for enterprise organisations
  • Session management with device tracking

​
User Isolation

Every database query enforces user isolation. You can only access your own:
  • Samples and analysis results
  • Chat conversations and messages
  • Reports and artifacts
  • Settings and preferences
There is no shared state between users. A database query that doesn’t verify userId ownership will not return results.

​
Rate Limiting

All API endpoints are protected by rate limiting via Upstash Redis:
EndpointLimit
Ask mode60 requests/minute
Agent mode20 requests/minute
File upload10 requests/minute
Other API routesVaries per endpoint
Rate limiting degrades gracefully — if the Redis connection is unavailable, requests are still allowed rather than blocking all users.

​
Billing Security

DECODA uses a fail-closed billing model:
  • Usage checks deny access on error (never fail-open)
  • Credit deductions are atomic — if deduction fails, the request is denied
  • Tier normalisation prevents privilege escalation — unknown tier values default to free
  • Development mode requires both NODE_ENV=development AND DEV_BILLING_BYPASS=true

​
What DECODA Does Not Do

  • No dynamic analysis — Malware samples are never executed. All analysis is static.
  • No data sharing — Your samples and results are not shared with other users or third parties.
  • No sample retention beyond your account — Deleting your account permanently removes all associated data.
  • No network access from sandboxes — There is no configuration option to enable network access in analysis VMs.