Security Policy

1. Operational Architecture

This portfolio operates as a hardened Next.js edge-rendered application. Security is implemented through defense-in-depth principles across the presentation, API, and database layers.

2. Core Security Practices

• Authentication & Authorization: Administrative access to the underlying SOC Dashboard mandates Authenticator Assurance Level 2 (AAL2) Multi-Factor Authentication via TOTP.
• Row Level Security (RLS): The Supabase PostgreSQL database implements strict RLS policies. Client-side queries are bound explicitly to authenticated sessions; unauthenticated traffic operates strictly via server-side API routes operating under principle-of-least-privilege service roles.
• Rate Limiting & Throttling: Anomalous traffic patterns, particularly against contact endpoints and the terminal component, trigger automated rate limiting and IP blacklisting mechanisms.
• Data Sanitization: All user-supplied inputs (including terminal commands and contact form payloads) undergo aggressive sanitization to mitigate Cross-Site Scripting (XSS) and SQL Injection (SQLi) vectors.
• Transport Security: All connections are strictly enforced over TLS 1.3, ensuring encrypted transit between clients, the Vercel edge network, and Supabase.

3. Privacy & Tracking

We deploy a custom telemetry engine that replaces invasive third-party trackers. Session tracking relies on cryptographically secure UUIDs, avoiding the collection of Personally Identifiable Information (PII) beyond what is explicitly submitted via forms. For detailed mechanics, refer to the Privacy Policy.

4. Incident Response & Disclosure

We actively monitor internal audit logs and real-time telemetry. In the event of a theoretical data breach impacting contact submissions, affected parties will be notified via email within 72 hours.

Independent security researchers are encouraged to report vulnerabilities under our Responsible Disclosure safe harbor.

5. Contact