Security & System Hardening Guide¶

Comprehensive technical guide covering authentication architecture, database protection, input sanitization, rate limiting, and HTTP security hardening in TidyFactor-Go.

1. Authentication & Session Architecture¶

Administrator access to the control panel (/admin) and protected API endpoints (/api/admin/*) is secured by session authentication and password hashing.

┌─────────────────────────────────────────────────────────┐
│              Admin Authentication Flow                  │
└───────────────────────────┬─────────────────────────────┘
                            │
       ┌────────────────────┼────────────────────┐
       ▼                    ▼                    ▼
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Bcrypt Hash │     │ IP Rate      │     │ Session      │
│  Verification│     │ Limiter      │     │ Cookies      │
│  (PHP 8.2+)  │     │ (5 attempts) │     │ (HttpOnly)   │
└──────────────┘     └──────────────┘     └──────────────┘

Key Security Protocols¶

Bcrypt Password Hashing: Passwords are saved as bcrypt hashes (PASSWORD_BCRYPT) in the SQLite users table or environment variable (ADMIN_PASSWORD_HASH). Authentication uses secure password_verify($password, $hash).
IP Brute-Force Rate Limiter: Failed login attempts are logged in the SQLite login_attempts table. Exceeding 5 failed attempts within 15 minutes triggers an immediate HTTP 429 Too Many Requests lockout.
Session Security: Session cookies enforce:
session.cookie_httponly = On: Prevents client-side XSS script access to session tokens.
session.cookie_secure = On: Mandates HTTPS transport in production environments.
session.cookie_samesite = Strict: Mitigates Cross-Site Request Forgery (CSRF).

2. Database Protection & SQL Injection Defense¶

All persistence in TidyFactor-Go is handled by PDO SQLite (backend/cms-api/storage/database.sqlite).

[!IMPORTANT] Prepared Statements: 100% of database queries execute through PDO prepared statements ($db->prepare()) with explicit parameter binding. String concatenation inside SQL queries is strictly prohibited across the codebase, completely eliminating SQL Injection vulnerabilities.

Transaction Safety & Self-Healing¶

WAL Journal Mode: SQLite Write-Ahead Logging allows concurrent reads while write locks execute.
5000ms Busy Timeout: Prevents write collisions and database locked exceptions under load.
Pre-Restore Safety Snapshots: Overwriting data via the Backup Manager automatically creates an immutable snapshot (site-pre-restore-{timestamp}.json) prior to transaction commit.
Baseline Self-Healing: Missing database files automatically rebuild from database-baseline.sqlite.

3. Input Sanitization & File Upload Security¶

Stored XSS Prevention (SVG Sanitization)¶

Uploaded SVG vector assets pass through enshrined/svg-sanitize prior to disk storage. This removes <script> tags, inline onload/onerror attributes, and javascript: URIs to prevent Stored XSS.

Path Traversal Defense¶

Media deletion requests (DELETE /api/media/delete) enforce basename() validation on input filenames to prevent path traversal directory breakouts (e.g. ../../etc/passwd).

DOS Protection (Inquiry FIFO Cap)¶

To prevent disk space exhaustion attacks, the contact form endpoint (POST /api/contact) enforces an automatic FIFO cap of 200 maximum records in the inquiries table. Older entries are automatically pruned.

4. HTTP Security Hardening & Headers¶

Server Security Headers¶

The root .htaccess enforces browser security policies:

Options -Indexes
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "no-referrer-when-downgrade"

Production Exception Masking¶

Backend route errors invoke Http::errorMessage($e). In production (APP_ENV=production), raw exception messages and stack traces are suppressed and replaced with generic error strings to prevent leaking database structure or environment details.