Back to Security Overview

Technical Security Details

Detailed technical documentation of security implementations, protocols, and architecture decisions.

Architecture Overview

eSolia Pulse is built on Cloudflare's edge infrastructure, providing global distribution with security built into every layer.

Cloudflare Pages

Edge-deployed SvelteKit application with automatic DDoS protection and Web Application Firewall (WAF).

Cloudflare D1

SQLite databases with encryption at rest. Multi-tenant isolation ensures complete data separation.

Cloudflare R2

S3-compatible object storage for evidence files with encryption at rest and signed URL access.

OWASP Top 10 Compliance

eSolia Pulse is designed with comprehensive mitigations for all OWASP Top 10 vulnerabilities. Below is detailed documentation of how each category is addressed.

A01

Broken Access Control

Unauthorized access to resources or actions beyond permitted scope.

Server-side authorization on every request

SvelteKit hooks validate JWT and permissions before any route handler executes

Role-based access control (RBAC)

Six distinct roles (owner, admin, admin_readonly, client_admin, client_user, client_readonly) with explicit permission checks

Multi-tenant isolation

Physical database separation per client organization - queries cannot cross tenant boundaries

Deny by default

All protected routes require explicit authentication - no public access to sensitive data

A02

Cryptographic Failures

Exposure of sensitive data due to weak or missing encryption.

TLS 1.3 for all connections

Cloudflare enforces modern TLS with automatic certificate management

Encryption at rest

All D1 databases and R2 storage encrypted by Cloudflare infrastructure

Secure password hashing

bcrypt with cost factor 10 - passwords never stored in plaintext

Secure key management

JWT secrets stored in Cloudflare Secrets (encrypted), never in code or environment files

A03

Injection

SQL, NoSQL, OS command, or LDAP injection through untrusted data.

Parameterized queries only

All database access uses D1 prepared statements with bound parameters - no string concatenation

Svelte auto-escaping

All template expressions automatically escaped - {@html} never used with user content

Input validation

Server-side validation of all user inputs with type checking and length limits

Content-Security-Policy

CSP headers restrict script sources and prevent inline script injection

A04

Insecure Design

Missing or ineffective security controls due to design flaws.

Security-first architecture

Multi-tenant isolation designed from day one - not bolted on later

Principle of least privilege

Users receive minimum permissions needed - readonly roles for viewers, limited write access for implementers

Defense in depth

Multiple security layers: Cloudflare WAF → Auth hooks → RBAC → Database isolation

Fail-secure defaults

On any auth error, access is denied - never fails open

A05

Security Misconfiguration

Insecure default configurations, incomplete setups, or verbose error messages.

Security headers configured

HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, CSP, Referrer-Policy

Production error handling

Generic error messages to users - detailed errors logged server-side only

No debug mode in production

Development-only features disabled in production builds

Secure cookie configuration

httpOnly, Secure, SameSite=Strict attributes on all session cookies

A06

Vulnerable and Outdated Components

Using components with known vulnerabilities or unsupported software.

Minimal dependencies

Only essential packages included - reduces attack surface

Automated vulnerability scanning

npm audit runs on every build, Dependabot alerts enabled for security updates

Rapid patching process

Critical vulnerabilities patched within 24 hours, high within 72 hours

Lock files committed

package-lock.json ensures reproducible builds with exact versions

A07

Identification and Authentication Failures

Weak authentication mechanisms or session management flaws.

Secure session management

JWT tokens with HS256 signing, stored in httpOnly cookies, 7-day expiration

Password strength enforcement

Minimum length requirements, stored with bcrypt (cost factor 10)

Server-side session validation

Every request validates JWT signature and checks user exists in database

Secure logout

Session cookie cleared with maxAge=0 on logout - immediate invalidation

A08

Software and Data Integrity Failures

Assumptions about software updates, critical data, or CI/CD pipelines without verification.

Signed JWT tokens

All session tokens cryptographically signed - tampering detected and rejected

Input validation on all mutations

Server-side validation of all form submissions and API requests

Audit trail

All data changes logged with user, timestamp, and before/after values for forensics

Trusted deployment pipeline

Cloudflare Pages deployment from verified GitHub repository only

A09

Security Logging and Monitoring Failures

Insufficient logging, detection, monitoring, and active response.

Comprehensive audit logging

All security-relevant events logged: login/logout, status changes, permission changes, evidence uploads

No sensitive data in logs

Passwords, tokens, and PII never logged - IP addresses hashed for privacy

Authentication event tracking

Failed login attempts logged with timestamp and source for anomaly detection

Cloudflare analytics

WAF logs, request analytics, and threat detection via Cloudflare dashboard

A10

Server-Side Request Forgery (SSRF)

Fetching remote resources without validating user-supplied URLs.

No user-controlled external requests

Application does not fetch URLs based on user input - SSRF vector eliminated

Controlled API integrations

Only pre-configured endpoints (Claude API for translation) - URLs hardcoded, not user-supplied

File upload validation

Evidence files uploaded directly to R2 - no URL-based fetching of external resources

Network isolation

Cloudflare Workers environment has no access to internal networks or metadata services

Authentication & Authorization

JWT Token Implementation

// Token configuration
Algorithm: HS256
Expiration: 7 days
Storage: httpOnly cookie

// Cookie attributes
{
  httpOnly: true,
  secure: true,        // HTTPS only
  sameSite: 'strict',  // CSRF protection
  path: '/',
  maxAge: 7 * 24 * 60 * 60  // 7 days
}

Server-Side Session Validation

Every request is validated through SvelteKit hooks before reaching any route:

  • JWT signature verification
  • Token expiration check
  • User existence validation against database
  • Role-based route protection

Role-Based Access Control (RBAC)

RoleScopePermissions
adminAll organizationsFull CRUD, user management, settings
admin_readonlyAll organizationsRead-only access to all data
userOwn organizationUpdate status, upload evidence
user_readonlyOwn organizationView dashboards and progress only

Data Protection

Encryption in Transit

  • TLS 1.3 for all connections
  • HSTS header enforced
  • Certificate managed by Cloudflare

Encryption at Rest

  • D1 databases encrypted by Cloudflare
  • R2 objects encrypted at rest
  • Key management by Cloudflare

Multi-Tenant Data Isolation

Each organization's data is completely isolated through database-level separation:

// Architecture: Central + Per-Client Databases
Central DB: User auth, organization metadata
Client DBs: Each organization has isolated D1 database

// All queries include tenant validation
const data = await clientDb
  .prepare('SELECT * FROM controls WHERE org_id = ?')
  .bind(user.organizationId)  // Always scoped to user's org
  .all();

Input Validation & Injection Prevention

SQL Injection Prevention

All database queries use D1 prepared statements with parameterized values:

// Safe: Parameterized query
await db.prepare('SELECT * FROM users WHERE email = ?')
  .bind(email)  // User input safely bound
  .first();

// Never: String concatenation (vulnerable)
// await db.prepare(`SELECT * FROM users WHERE email = '${email}'`)

XSS Prevention

  • Svelte auto-escapes all template expressions
  • No use of {@html} with user content
  • Content-Security-Policy headers configured

CSRF Protection

  • SameSite=Strict cookie attribute
  • SvelteKit form actions with built-in CSRF protection
  • Origin header validation

Security Headers

The following security headers are configured via Cloudflare and application middleware:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'

Audit Logging

Comprehensive audit logging for compliance and security monitoring:

Events Logged

  • User authentication (login/logout)
  • Status changes on controls
  • Evidence uploads
  • User/role modifications
  • Settings changes

Data Captured

  • Timestamp (UTC)
  • User ID and role
  • Action type
  • Resource affected
  • Before/after values

Note: Sensitive data (passwords, tokens) is never logged. IP addresses are hashed for privacy.

Regional Data Placement

Data residency options to meet regulatory requirements:

🌏

APAC

Asia-Pacific region

🇪🇺

EU

European Union (GDPR)

🇺🇸

NA

North America

Dependency Security

We maintain minimal dependencies and perform regular security audits:

  • npm audit run on every build
  • Automated Dependabot alerts enabled
  • Critical vulnerabilities patched within 24 hours
  • Lock files committed for reproducible builds

Questions about our security implementation?

Contact Security Team