Security Whitepaper

1. Infrastructure Overview

Festie is deployed on self-hosted on-premise infrastructure with a robust, production-grade architecture designed for reliability and security.

Core Architecture

Application Servers: PM2 cluster mode with 4 Node.js instances for horizontal scalability, automatic failover, and zero-downtime deployments

Database: PostgreSQL 16 with replication support, transaction logging, and ACID compliance for data integrity

Caching Layer: Redis 7 (optional) for session storage, rate limit counters, and real-time data

Reverse Proxy: nginx with SSL/TLS termination, request routing, and DDoS mitigation

Transport Layer Security

Minimum TLS Version: TLS 1.2 with support for TLS 1.3 where supported
Cipher Suites: Modern, authenticated encryption algorithms (AEAD) excluding weak or deprecated ciphers
Certificate Management: Automated SSL/TLS certificate provisioning with renewal mechanisms
HSTS Headers: Strict-Transport-Security enforced to prevent downgrade attacks
Service Worker Integrity: Offline-capable PWA with cache-first strategy and version-controlled updates

Network Segmentation

The application infrastructure is segmented to isolate components and limit the attack surface. Database servers operate in restricted network zones with firewall rules limiting access to application servers only. Redis instances (if used) are accessible exclusively from the application layer.

2. Authentication & Session Management

Authentication and session management are critical components of the security architecture, employing industry-standard practices and timing-safe implementations.

Password Hashing & Storage

Algorithm: Scrypt key derivation function with memory-hard properties resistant to GPU-accelerated brute-force attacks

Parameters: 64-byte derived key length, cryptographically random salt per password, high cost factor to increase computation time

Timing Safety: Password comparison uses constant-time string comparison to prevent timing-based attacks

Passwords are never stored in plaintext and cannot be recovered or reset by administrators. Users requesting a forgotten password receive a time-limited reset token instead.

Session Tokens & Authentication Cookies

Token Format: Cryptographically random tokens (minimum 256 bits entropy)
Storage: Tokens are hashed using SHA-256 before database storage; raw tokens never stored on disk
Cookie Configuration: HTTP-only flag prevents JavaScript access, Secure flag enforced on HTTPS connections, SameSite=Strict prevents CSRF
Session Duration: 24-hour absolute timeout, sliding window renewal on activity

Refresh Token Rotation

Refresh tokens implement automatic rotation to mitigate token replay attacks:

TTL: 90-day maximum lifetime
Rotation: Automatic issuance of new refresh token on each use; previous token invalidated
Reuse Detection: Rotation family tracking to detect potential token theft
Revocation: Bulk invalidation of refresh tokens on password change or logout-all operations

Account Lockout & Brute-Force Protection

Metric	Threshold	Action
Consecutive failed login attempts	10	Account locked for 15 minutes
Lockout duration	15 minutes	Automatic unlock; user can unlock via email
Failed attempts reset	After successful login	Counter resets to zero

Rate Limiting on Authentication Endpoints

Login Endpoint: 10 requests per 5-minute window per IP address

Password Reset: 5 requests per 15-minute window per email address

Registration: 5 requests per hour per IP address

Rate limiting is enforced at the reverse proxy layer with per-IP and per-user tracking. Attempts to bypass rate limiting via distributed requests are mitigated through adaptive thresholds.

Multi-Device Session Management

Users can maintain multiple concurrent sessions across devices. Session invalidation can be triggered by:

User-initiated logout (single device)
Logout from all devices (invalidates all active sessions)
Password change (auto-invalidates all sessions for security)
Administrator action (in case of security incident)

3. Input Validation & Injection Prevention

Comprehensive input validation is implemented across all API endpoints to prevent injection attacks and enforce data consistency.

Schema Validation

Framework: Zod runtime schema validation on all API request bodies, query parameters, and path parameters

Coverage: 100% of API endpoints validate inputs before processing

Type Safety: TypeScript types derived from Zod schemas ensure consistency between runtime and compile-time validation

Invalid requests are rejected with 400 Bad Request responses before reaching business logic. Validation errors are logged for intrusion detection.

SQL Injection Prevention

Parameterized Queries: All database queries use parameterized queries (prepared statements) exclusively
ORM Usage: Database access through query builders and ORMs that enforce parameterization
Dynamic Query Prevention: Raw SQL queries prohibited; code reviews and linting detect violations
Zero Surface: No SQL injection surface despite handling user-controlled data in filters, sorting, and pagination

Cross-Site Scripting (XSS) Prevention

Output Encoding: All user-generated content is HTML-escaped before rendering in templates
Content Security Policy: CSP headers enforce strict policies against inline scripts and unauthorized resource loading
Per-Request Nonces: Script execution nonces generated per-request and validated, preventing execution of injected scripts
React/JSX: Client-side rendering with React automatically escapes content, providing XSS protection by default

Content Security Policy (CSP)

The application implements a restrictive CSP policy limiting script execution, style loading, and resource origins:

Script-Src: 'self' with per-request nonce for inline scripts
Style-Src: 'self' and Google Fonts for web fonts
Img-Src: data:, blob:, 'self', and whitelisted CDNs
Connect-Src: Limited to same origin for API calls
Frame-Ancestors: 'none' prevents clickjacking via frame embedding

CSRF Protection

Origin Enforcement: State-changing requests (POST, PUT, DELETE) require valid Origin and Referer headers matching the application domain

Token-Based Protection: Optional CSRF tokens for additional protection on sensitive operations

SameSite Cookies: Session cookies enforced with SameSite=Strict preventing cross-site cookie transmission

Other Injection Attacks

Header Injection: HTTP headers validated to prevent CRLF injection attacks
Path Traversal: File operations validated to prevent directory traversal attacks
Command Injection: External command execution avoided; commands use parameterized APIs instead of shell interpolation

4. Rate Limiting & DDoS Mitigation

Multi-layered rate limiting protects against brute-force attacks, DDoS, and resource exhaustion attacks.

Rate Limiting Tiers

Endpoint Category	Rate Limit	Window	Tracking
General API	120 requests	1 minute	Per IP + Per User
Authentication	10 requests	5 minutes	Per IP
WebSocket Connections	30 messages	1 minute	Per User
File Uploads	10 uploads	1 hour	Per User

Implementation Details

Storage Backend: Redis-backed rate limiting for distributed deployments with in-memory fallback for single-instance deployments

Sliding Window: Sliding window rate limiting prevents burst attacks at window boundaries

Distributed Coordination: All instances sync rate limit state via Redis, preventing limit bypass through load balancer switching

DDoS Mitigation

nginx Rate Limiting: Reverse proxy enforces upstream rate limits before requests reach the application
Connection Limits: Maximum concurrent connections per IP to prevent resource exhaustion
Slowloris Mitigation: Request timeout enforcement and connection draining to prevent slow-read attacks
Adaptive Thresholds: Rate limits adjusted based on traffic patterns to identify and isolate attack sources
Cloudflare DDoS Protection: Optional integration with Cloudflare for Layer 3-7 DDoS mitigation

Response Headers

Rate-limited responses include headers informing clients of their current limits:

RateLimit-Limit: Maximum requests allowed in the window
RateLimit-Remaining: Number of requests remaining before limit
RateLimit-Reset: Unix timestamp when limit resets
Retry-After: Seconds to wait before retrying (when limit exceeded)

5. Data Protection

Data protection encompasses encryption, hashing, retention policies, and compliance with privacy regulations.

Encryption in Transit

Protocol: TLS 1.2 minimum (TLS 1.3 preferred) for all data transmission

Coverage: All API endpoints, WebSocket connections, and file transfers require HTTPS

Enforcement: HSTS headers enforce TLS for minimum 1 year; preload list inclusion prevents initial insecure connections

Encryption at Rest

User passwords and authentication tokens are never stored in plaintext:

Passwords: Hashed with Scrypt (memory-hard KDF); hashes cannot be reversed to plaintext
Tokens: Hashed with SHA-256 before storage; tokens not recoverable from database
Session Data: Stored in Redis (encrypted if TLS is used) or encrypted at rest in PostgreSQL

Data Retention Policy

Data Category	Retention Period	Deletion Method
User Account Data	Lifetime of account	30-day soft delete with reactivation option
Backups	7 daily + 4 weekly cycles (28 days)	Automatic purge after retention period
Audit Logs	12 months	Automatic archival and deletion
Session Data	24 hours	Automatic expiration and invalidation

GDPR Compliance

Article 15 (Right of Access): Data export API endpoint returns user data in JSON format

Article 17 (Right to Erasure): Account deletion initiates soft-delete with 30-day grace period; permanent deletion after grace period expires

Article 20 (Data Portability): Exported data in standard, machine-readable format enables transfer to other services

Data subject requests are processed within 30 days (up to 60 days for complex requests). Identity verification required before processing.

Soft-Delete & Account Reactivation

User deletion requests are not immediately permanent to prevent accidental data loss:

Grace Period: 30 days after deletion request before permanent removal
Reactivation: Users can reactivate accounts by logging in with credentials during grace period
Data Accessibility: Data inaccessible to user but retained for recovery during grace period
Irreversible Deletion: After 30 days, data permanently deleted and unrecoverable

Terms of Service & Consent Versioning

Account creation requires acceptance of current Terms of Service and Privacy Policy. Versions are tracked:

Each user record stores accepted ToS/Privacy version and acceptance timestamp
Material changes require explicit re-acceptance before continued service use
30-day notice period for material policy changes with continued-use-as-acceptance

6. Audit Logging

Comprehensive audit logging enables security monitoring, investigation of incidents, and compliance with regulatory requirements.

Logged Events

The following events are logged for audit purposes:

Authentication: Login attempts (successful and failed), password changes, token generation
Data Mutations: All create, update, delete operations on user data with before/after states
Permission Changes: Role assignments, crew membership changes, permission grants
Administrative Actions: Admin operations, configuration changes, user account modifications
Security Events: Rate limit violations, failed validations, suspicious patterns

Log Contents

Actor: User ID or system component responsible for the action

Action: Type of operation (create, update, delete, login, etc.)

Resource: Entity affected by the action and its ID

IP Address: Source IP address of the request

Timestamp: UTC timestamp with millisecond precision

Request ID: Correlation ID for tracing related requests

Result: Success/failure status and error messages if applicable

Log Storage & Access

Storage: PostgreSQL with tamper-evident checksums
Retention: 12-month retention policy with automatic archival and deletion
Access Control: Restricted to administrators; all log access logged
Query Interface: Admin panel with filtering by user, action, date range, result status
Export: Bulk export capabilities for security investigations and audits

Request Tracing

Request IDs enable correlation of logs across multiple services and instances:

Unique request ID generated on HTTP request entry
ID propagated through all downstream requests and logs
Request ID included in API response headers for client-side tracing
Enables reconstruction of complete request flow for security analysis

7. Backup & Recovery

Automated backup and disaster recovery procedures ensure business continuity and data preservation.

Backup Schedule

Frequency: PostgreSQL full backup every 6 hours (4 backups per day)

Compression: Gzip compression reduces backup size by 70-80%

Retention: 7 daily backups + 4 weekly backups (28-day rolling window)

Retention Policy

Backup Type	Age	Quantity	Total Retention
Daily Backups	Last 7 days	7 backups	7 days
Weekly Backups	Last 4 weeks	4 backups	4 weeks
Oldest Backup	Previous weekly	1 backup	~28 days total

Backup Integrity

Checksums: SHA-256 checksums computed on all backups for integrity verification
Test Restores: Monthly restoration tests validate backup integrity and recovery procedures
Encryption: Backups encrypted at rest using AES-256 encryption
Offsite Replication: Backups replicated to geographically distributed storage for disaster recovery

Recovery Procedures

Tested and documented procedures enable rapid recovery from data loss or system failures:

RTO (Recovery Time Objective): 1-2 hours maximum downtime for full restoration
RPO (Recovery Point Objective): 6 hours maximum data loss in worst-case scenario
Partial Recovery: Point-in-time recovery to specific timestamps for ransomware or data corruption scenarios
Verification: Post-recovery integrity checks confirm data consistency before serving

Transaction Logging

PostgreSQL Write-Ahead Logging (WAL) enables point-in-time recovery beyond backup snapshots:

WAL files retained for 7 days enabling recovery to any point within the window
Continuous archival of WAL files to separate storage for extended recovery window
Prevents data loss from the last backup snapshot to the point of failure

8. Dependency Management

Third-party dependencies are carefully managed and monitored for security vulnerabilities.

Vulnerability Scanning

npm audit: Automated dependency vulnerability scanning in CI/CD pipeline on every commit

GitHub Security: Automated Dependabot alerts for vulnerable dependencies with auto-remediation PRs

CI Pipeline: Builds fail if high or critical vulnerabilities detected; manual override permitted only for false positives

Dependency Updates

Update Frequency: Minor and patch updates applied within 7 days of release
Major Versions: Evaluated for breaking changes; updated quarterly or as needed
Security Patches: Applied immediately upon release regardless of version constraints
Testing: Automated tests run on updated dependencies to catch regressions

Dependency Lockfile

Exact dependency versions locked to prevent unintended upgrades:

Lockfile committed to version control ensuring reproducible builds
Production deployments use locked versions exclusively
Regular lockfile updates maintain security and patch levels

Direct Dependency Audit

Direct dependencies (not transitive) are reviewed annually for:

Maintenance status and community activity
Security track record and vulnerability history
License compatibility with project requirements
Deprecation status and roadmap

9. Incident Response

A comprehensive incident response program enables rapid detection, investigation, and resolution of security incidents.

Vulnerability Disclosure

Festie follows responsible vulnerability disclosure practices per RFC 9116:

Security.txt File: /.well-known/security.txt published with vulnerability disclosure contact and policy

Reporting Vulnerabilities

Email: security@festie.us

Response Commitment: 48-hour acknowledgment of vulnerability reports

Disclosure Timeline: 90-day coordinated disclosure window for remediation before public disclosure

Response Process

Triage: Severity assessment and impact analysis within 24 hours
Investigation: Technical investigation to understand vulnerability scope and root cause
Remediation: Development of fix with priority based on severity and exploitability
Testing: Comprehensive testing of fix in production-like environment
Deployment: Rapid deployment of fix to production; emergency updates if necessary
Disclosure: Coordinated disclosure with researcher and public notice after fix is deployed

Severity Classification

Severity	Description	Fix Timeline
Critical	Remote code execution, data exfiltration, complete system compromise	< 24 hours
High	Authentication bypass, privilege escalation, significant data exposure	< 72 hours
Medium	Information disclosure, limited impact vulnerabilities	< 2 weeks
Low	Minor security issues with minimal impact	Next release cycle

Post-Incident Process

Root cause analysis to identify systemic issues
Security review of related components for similar vulnerabilities
Process improvements to prevent recurrence
Transparency communication with affected users if data exposed

10. What This Document Does Not Cover

This whitepaper focuses on application-layer security and infrastructure. The following are intentionally excluded for operational security:

Infrastructure-Specific Information

Specific server IP addresses and network topology
Detailed firewall rules and network configuration
Physical data center locations and disaster recovery sites
Server hostnames or internal domain names

Tool & Version Information

Specific versions of security tools and vulnerability scanners used
Names and versions of WAF (Web Application Firewall) rules
Intrusion detection system configurations
Specific monitoring and alerting tool versions

Incident Details

Details of past security incidents or breaches
Specific vulnerability remediation timelines from past incidents
Names of users or systems affected by security events
Attack vectors or techniques observed in production

Operational Procedures

Detailed incident response runbooks
Administrator access procedures and credential management
Deployment procedures and release processes
On-call rotation and escalation procedures

Why These Are Excluded

Specific infrastructure and procedural details are withheld to prevent providing roadmaps for potential attackers. Security assessments requiring this level of detail are conducted under NDA through separate vendor security assessments.

Conclusion

Festie implements a comprehensive, defense-in-depth security architecture addressing authentication, data protection, injection prevention, rate limiting, audit logging, and incident response. The application is designed to be resilient against common web application attacks while maintaining usability and performance.

This whitepaper documents existing security practices as of March 2026. Security is an ongoing process requiring continuous improvement, monitoring, and adaptation to emerging threats. For vendor security assessments or specific security questions, contact security@festie.us.

Contact & Questions

Security Issues: security@festie.us

Vulnerability Disclosure: security@festie.us

Service URL: https://festie.us

Security Policy: /.well-known/security.txt

For additional information regarding the security of Festie, please contact our security team. Inquiries are responded to within 48 hours during business days.

Table of Contents