Security Architecture

Overview

The Refresh App Web implements defense-in-depth security with multiple layers of protection: network security, authentication via FusionAuth, authorization via role-based permissions, data protection, and application security. This document describes the comprehensive security model.

Security Layers

┌─────────────────────────────────────────────────────────────────┐
│                    Network Security                              │
│  • HTTPS enforcement                                             │
│  • HSTS, CSP, security headers                                   │
│  • CORS policies                                                 │
└───────────────────┬─────────────────────────────────────────────┘
                    │
┌───────────────────▼─────────────────────────────────────────────┐
│                  Authentication (FusionAuth)                     │
│  • OAuth 2.0 / OIDC                                              │
│  • Self-registration with verification                           │
│  • MFA support                                                   │
│  • M2M via Entity Grants                                         │
└───────────────────┬─────────────────────────────────────────────┘
                    │
┌───────────────────▼─────────────────────────────────────────────┐
│                  Authorization                                   │
│  • FusionAuth roles → Database permissions                       │
│  • Granular resource:action permissions                          │
│  • Row-Level Security (RLS)                                      │
└───────────────────┬─────────────────────────────────────────────┘
                    │
┌───────────────────▼─────────────────────────────────────────────┐
│                  Data Protection                                 │
│  • Encryption in transit (TLS 1.3)                               │
│  • Tenant isolation via RLS                                      │
│  • Personal vs work data separation                              │
│  • Secret management (AWS SSM, Cloudflare)                       │
└───────────────────┬─────────────────────────────────────────────┘
                    │
┌───────────────────▼─────────────────────────────────────────────┐
│              Application Security                                │
│  • Input validation (Zod schemas)                                │
│  • XSS protection                                                │
│  • CSRF protection                                               │
│  • SQL injection prevention (Drizzle ORM)                        │
└─────────────────────────────────────────────────────────────────┘

Authentication Security

FusionAuth handles all identity concerns. See Authentication Flow for complete details.

Key Security Properties

Property	Value
JWT Algorithm	RS256 (asymmetric)
Access Token TTL	60 minutes
Refresh Token TTL	30 days
MFA	TOTP, SMS (configurable)
Self-Registration	Enabled with email verification

Self-Registration Safeguards

1. Email verification required - Must verify before full access

2. No default tenant access - New users get personal account only

3. HRIS-based provisioning - Work accounts created by sync, not self-registration

4. Rate limiting - FusionAuth limits registration attempts

Authorization Security

See Authorization for the complete role and permission model.

Key Security Properties

Layer	What It Enforces
Application	Permission checks before API operations
RLS	Database-level tenant isolation (cannot be bypassed)

Row-Level Security (RLS)

RLS prevents data leakage at the database level using two key functions:

auth_user() - Resolves FusionAuth JWT sub to internal user_id:

-- In RLS policies, replaces direct UUID casts
auth_user(auth.user_id())  -- Returns internal user UUID from user_auth_identities

get_permission() - Returns permission check with bypass info:

-- Returns: { is_authorized: boolean, bypass_rls: boolean, bound_tenant_id: uuid }
get_permission(auth.session(), ARRAY['surveys:create', 'surveys:update'])

-- Usage in RLS policies:
(get_permission(auth.session(), ARRAY['surveys:get'])).is_authorized
(get_permission(auth.session(), ARRAY['surveys:get'])).bypass_rls

Example RLS Policy with bypass support:

CREATE POLICY tenant_isolation ON survey_responses
  USING (
    (get_permission(auth.session(), ARRAY['surveys:get'])).is_authorized
    AND (
      -- Internal admins can bypass tenant isolation
      (get_permission(auth.session(), ARRAY['surveys:get'])).bypass_rls
      OR tenant_id IN (
        SELECT tenant_id FROM tenant_users
        WHERE user_id = auth_user(auth.user_id()) AND status = 'active'
      )
    )
  );

Benefits:

• Cannot be bypassed from application code

• Enforced by PostgreSQL on every query

• Automatic filtering without explicit WHERE clauses

• Permission checks happen at database level

• bypass_rls allows internal employees to access all tenants for support

• Identity resolution is database-side (future-proof for api-core migration)

Data Protection

Encryption in Transit

Connection	Encryption
Browser → App	TLS 1.3 (Cloudflare)
App → FusionAuth	TLS 1.3
App → Neon DB	TLS 1.3
Service → Service	TLS 1.3

Encryption at Rest

Storage	Encryption
Neon Postgres	AES-256 (Neon managed)
Cloudflare R2	AES-256 (Cloudflare managed)
FusionAuth	AES-256 (FusionAuth managed)

Tenant Data Isolation

Multi-layer isolation ensures tenants can never access each other's data:

1. Identity Layer - FusionAuth user → user_identities → internal user_id

2. Membership Layer - tenant_users validates access

3. Data Layer - RLS policies filter by tenant_id

Personal vs Work Data Separation

Personal data (therapy sessions, anonymous reports) is owned by the personal user_id and never visible to tenant admins. Work data (surveys, HRIS records) is owned by the work user_id.

See User Management for the complete data ownership model.

Secret Management

AWS SSM Parameter Store:

• Encrypted with AWS KMS

• IAM role-based access

• Retrieved during deployment

Cloudflare Secrets:

• Uploaded via Wrangler CLI

• Encrypted in Workers

• Accessed via env object

# Fetch from SSM
aws ssm get-parameters-by-path \
  --path "/app-web/$ENV/" \
  --with-decryption

# Upload to Cloudflare
echo "$SECRET_VALUE" | npx wrangler secret put SECRET_NAME

Network Security

HTTPS Enforcement

// hooks.server.ts
if (!dev && event.url.protocol === 'http:') {
	return Response.redirect(event.url.href.replace('http://', 'https://'), 301);
}

Security Headers

response.headers.set('X-Content-Type-Options', 'nosniff');
response.headers.set('X-Frame-Options', 'DENY');
response.headers.set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload');
response.headers.set('X-XSS-Protection', '1; mode=block');
response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin');

CORS Policy

// API routes
if (event.url.pathname.startsWith('/api')) {
	response.headers.set('Access-Control-Allow-Origin', ALLOWED_ORIGINS);
	response.headers.set('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
	response.headers.set('Access-Control-Allow-Headers', 'Content-Type, Authorization, X-Tenant-Id');
}

Application Security

Input Validation

import { z } from 'zod';

const createDocumentSchema = z.object({
	title: z.string().min(1).max(200),
	content: z.string().max(50000),
	tenantId: z.string().uuid()
});

export async function POST({ request, locals }) {
	const body = await request.json();
	const validated = createDocumentSchema.parse(body); // Throws on invalid
	// Safe to use validated data
}

Email Normalization

Critical: All email handling must be case-insensitive to prevent identity matching failures.

// Always normalize emails before storage or comparison
function normalizeEmail(email: string): string {
	return email.toLowerCase().trim();
}

// Database queries must use case-insensitive matching
const identity = await db.query.userIdentities.findFirst({
	where: sql`LOWER(${userIdentities.email}) = ${normalizeEmail(inputEmail)}`
});

Apply to:

• Identity resolution (FusionAuth JWT email → user_identities)

• Account linking (verification of ownership)

• Notification routing

• HRIS sync email matching

HRIS Email	User Logs In As	Match?
[email protected]	[email protected]	✅ Yes
[email protected]	[email protected]	✅ Yes
[email protected]	[email protected]	✅ Yes

XSS Prevention

• Svelte automatically escapes output

• {@html} only with sanitized content

• CSP headers (when enabled)

import sanitizeHtml from 'sanitize-html';

const cleanHtml = sanitizeHtml(userInput, {
	allowedTags: ['b', 'i', 'em', 'strong', 'a'],
	allowedAttributes: { a: ['href'] }
});

CSRF Protection

• SameSite cookies (lax)

• Origin header validation

• State parameter in OAuth flow

SQL Injection Prevention

Drizzle ORM with parameterized queries:

// Safe - parameterized
const docs = await db.query.documents.findMany({
	where: eq(documents.tenantId, tenantId)
});

// Safe - query builder
const result = await db.select().from(documents).where(eq(documents.id, docId));

Attack Prevention

Attack	Prevention
Credential stuffing	FusionAuth rate limiting, account lockout
Session hijacking	HTTP-only cookies, short JWT lifetime
Token forgery	RS256 signing, JWKS validation
Tenant ID tampering	JWT-embedded tenant_id, RLS enforcement
Cross-tenant access	RLS policies, tenant_users validation
XSS	Svelte escaping, CSP, sanitization
CSRF	SameSite cookies, origin validation
SQL injection	Drizzle ORM, parameterized queries
Privilege escalation	Server-side permission checks

Audit Logging

Events to Log

Event	Data Captured
Login success/failure	User, IP, timestamp, method
Permission denied	User, resource, required permission
Data export	User, tenant, data type
Role changes	Admin, target user, old/new role
HRIS sync	Tenant, records processed
Account linking	User, identities linked

Log Structure

interface AuditLog {
	id: string;
	timestamp: Date;
	eventType: string;
	userId: string | null;
	tenantId: string | null;
	ipAddress: string;
	userAgent: string;
	details: Record<string, unknown>;
}

Compliance

GDPR

Requirement	Implementation
Data minimization	Only collect necessary data
Right to access	User can view all their data
Right to rectification	User can update their data
Right to erasure	User can request deletion
Data portability	Export functionality
Consent	Privacy policy acceptance

Data Deletion Flow

1. User requests deletion
2. Find all linked user records
3. Delete user_identities
4. Delete FusionAuth users
5. Anonymize users records:
   - is_anonymized = true
   - name = NULL
6. Delete user_private records
7. user_ids preserved for FK integrity

Security Checklist

Before Deployment

• All secrets in AWS SSM/Cloudflare

• HTTPS enforced

• Security headers configured

• RLS policies enabled and tested

• FusionAuth application configured

• JWT validation implemented

• Permission checks on all endpoints

• Input validation on all forms

• Dependencies up to date

• No hardcoded credentials

Regular Audits

• Review user permissions

• Check for unused accounts

• Scan dependencies (pnpm audit)

• Review audit logs

• Test RLS policies

• Verify JWT expiration working

• Test permission enforcement

• Review FusionAuth logs

Incident Response

Security Monitoring

• Cloudflare Analytics (request patterns, errors)

• FusionAuth logs (authentication events)

• Application logs (permission denials)

Key Metrics

• Failed login attempts

• 401/403 errors

• Unusual request patterns

• Large data exports

• Cross-tenant access attempts

Related Documentation

• Authentication Flow - FusionAuth setup

• User Management - Identity lifecycle

• Authorization - Permission model

• Multi-Tenancy - Tenant isolation

---

Last updated: December 2025