Security Practices

Data encryption

At rest

All data is stored in Supabase (PostgreSQL on AWS). Supabase uses AES-256 encryption for all data at rest. This means even if someone gained physical access to storage media, your data would be unreadable without the encryption keys, which are managed by AWS KMS.

In transit

All connections use TLS 1.2 minimum, TLS 1.3 preferred. Cloudflare Pages (our hosting) enforces HTTPS everywhere with HSTS (HTTP Strict Transport Security). Direct HTTP connections are automatically redirected to HTTPS. Certificate management is handled by Let's Encrypt via Cloudflare.

Passwords

Passwords are hashed using bcrypt with a strong cost factor by Supabase Auth. We never store, log, or see plaintext passwords. Password reset uses a time-limited one-time link sent to your verified email address.

Access controls

Row-Level Security (RLS)

Every table in our database has Row-Level Security enabled. This means the database itself enforces that you can only read and write your own organization's data. Even if an application bug bypassed application-level checks, the database would reject unauthorized queries. This is defense-in-depth.

Authentication

Authentication is handled by Supabase Auth using JWT tokens. Tokens are short-lived and automatically refreshed. Sessions expire after inactivity. We use httpOnly cookies to prevent XSS from accessing session tokens.

Admin access

Admin endpoints (jurisdiction update review) require a separate admin secret token stored only in server environment variables. Admin tokens are never logged, never exposed to clients, and can only be used server-side.

Application security

Input validation

Every API endpoint validates inputs using Zod schema validation before any database operation. Invalid inputs are rejected with descriptive errors before reaching any downstream code. This eliminates whole classes of injection attacks.

SQL injection prevention

We use the Supabase client library exclusively for database access. All queries use parameterized queries under the hood — no string concatenation, no raw SQL with user input. SQL injection is structurally prevented, not just validated against.

Cross-Site Scripting (XSS)

React (used by Next.js) escapes all output by default. We do not use dangerouslySetInnerHTML with user-supplied content. Content Security Policy headers restrict script sources.

CSRF protection

API routes that modify data use httpOnly cookies for auth (not URL parameters) and validate the Origin header. State-changing operations require authenticated sessions.

Rate limiting

API routes are rate-limited to prevent abuse and brute-force attacks. Authentication endpoints have stricter limits. Cloudflare's edge network provides additional DDoS mitigation.

Tamper-evident evidence vault

Compliance evidence is only useful if you can prove it has not been altered. Aegis Firma's evidence vault is built so that tampering is not just prevented — it is mathematically detectable.

Ed25519-signed records

Every compliance report and evidence record is signed with an Ed25519 digital signature when it is created or updated. The signature covers a canonical hash of the record. The signing private key is held only in a server environment variable and is never written to the database.

Daily Merkle-root anchoring

Once per day, the signed evidence records are hashed into a Merkle tree and the single root hash is recorded. Each day's root is chained to the previous day's, so no historical record can be back-dated, edited, or removed without breaking the chain — and any break is detectable.

SHA-256 document integrity

Every uploaded document has a SHA-256 hash computed at upload. A single changed byte produces a different hash, making any modification to a stored file detectable.

Independent verification

Verification does not require trusting our servers. The signature and public key are stored with each record, so a report can be checked against its public key by anyone. You can verify a report hash yourself on our Trust page — no account required.

Security headers

All pages are served with the following security headers (abbreviated — see full CSP breakdown for directive-by-directive explanation):

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'unsafe-inline' https://challenges.cloudflare.com
             https://static.cloudflareinsights.com;
  connect-src 'self' https://*.supabase.co wss://*.supabase.co
              https://api.lemonsqueezy.com https://challenges.cloudflare.com
              https://cloudflareinsights.com;
  img-src 'self' data: blob: https://*.supabase.co;
  frame-src 'none'; frame-ancestors 'none';
  object-src 'none'; base-uri 'self'; form-action 'self';
  upgrade-insecure-requests

X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(self)
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin

The connect-src allowlist contains only Supabase (your data), LemonSqueezy (billing), and Cloudflare Turnstile (anti-bot). No analytics, no ad networks. View full CSP transparency page →

Infrastructure

Hosting: Cloudflare Pages

Aegis Firma is hosted on Cloudflare Pages' global edge network. Cloudflare is SOC 2 Type 2 certified. Server-side code runs in isolated serverless functions. No persistent servers mean no servers to patch or misconfigure.

Database: Supabase

Database runs on Supabase (PostgreSQL on AWS). Supabase is SOC 2 Type 2 certified. Automated daily backups with 7-day retention. Point-in-time recovery available. Connection pooling via PgBouncer. Database is not publicly accessible — only accessible via Supabase client with valid JWT.

Secrets management

All API keys, database credentials, and secrets are stored as Cloudflare Pages environment variables. They are never hardcoded in source code, never logged, and never exposed to clients. We run automated secret scanning before every deployment to catch accidental exposure.

Sub-processors

We deliberately keep our vendor list short. Four sub-processors handle data on our behalf. We do not sell, rent, or share your data with anyone — no advertising networks, no data brokers.

A Data Processing Agreement is in place with each sub-processor. For the full table, data-residency detail, and our CAIQ v4 self-assessment, see the detailed security posture. Our customer DPA is at /legal/dpa.

What we're honest about

We believe in transparency, including about our limitations:

• !We have not yet undergone a formal third-party security audit (planned after Series A). We use free tools: OWASP ZAP scans, Mozilla Observatory, automated secret scanning.
• !We are not SOC 2 certified yet. Planned for when revenue supports the $15-30K cost.
• !We are a small team. We take security seriously but are not a dedicated security company.
• !If you find a security vulnerability, please report it to security@aegisfirma.com. We will respond within 24 hours and credit you publicly if you want.

Continuous security scanning

We run automated security scans on a continuous basis — not just at launch. Our security posture is checked weekly, not once at deployment and forgotten.

Security scan results are aggregated into an internal /admin/security-report dashboard. We publish a quarterly security transparency report — see our blog for past reports.

Responsible disclosure program

We operate a public responsible disclosure program. If you find a vulnerability, we want to know. We will acknowledge your report within 48 hours and aim to fix verified issues within 90 days. We will not pursue legal action against good-faith security researchers.

Report a vulnerability

If you discover a security vulnerability, please email security@aegisfirma.com with a description of the vulnerability and steps to reproduce. We will acknowledge your report within 48 hours, investigate promptly, and keep you informed of our progress. We will not take legal action against good-faith security research.

Please do not publicly disclose the vulnerability until we have had a reasonable time to address it — typically 7 days for critical issues and 90 days for others. See our full disclosure policy.

Disaster Recovery & Incident Playbooks

Our documented DR runbook covers RTO (4h) / RPO (24h) targets, backup restore test log, and data loss scenarios. Incident playbooks cover account takeover, vendor compromise (Supabase, Cloudflare, LemonSqueezy), legal hold, breach notification templates (72h GDPR/UAE PDPL,30-day CA breach statute), and post-incident review template.

Detailed security posture

For enterprise procurement, security questionnaires, or vendor due diligence, see our detailed Security Posture page covering: encryption details, sub-processor table, data residency, incident response SLA, backup & recovery, access controls, change management, SBOM, customer data handling, AI training data policy, and our CAIQ v4 self-assessment.