Security First. Always.

Infrastructure

Symlfy runs on Google Cloud Platform, which holds SOC 2 Type II, ISO 27001, PCI DSS Level 1, and FedRAMP Moderate certifications. All infrastructure is defined as code (Terraform) and deployed to the us-central1 region.

Network Architecture

• All Cloud Run services are internal-only. No service is accessible from the public internet. The Global HTTPS Load Balancer is the sole entry point.
• Cloud Armor WAF with deny-by-default policy. Only explicitly whitelisted paths and hostnames are allowed. OWASP Top 10 protection (XSS, SQLi, LFI, RFI, protocol attacks), rate limiting, and Layer 7 DDoS protection.
• Database has no public IP. Cloud SQL is accessible only via private VPC connector. SSL is mandatory on all database connections.
• Binary Authorization enforced on all deployments. Only images built by the project's Cloud Build can be deployed — prevents supply chain attacks.

Encryption

• At rest: AES-256 encryption on all data (Cloud SQL, Cloud Storage). TOTP secrets and OAuth tokens encrypted with AES-256-GCM application-level encryption.
• In transit: TLS 1.2+ with MODERN cipher suites. HSTS headers with preload. No legacy protocols.
• Key management: Encryption keys stored in GCP Secret Manager. Automated rotation every 90 days with zero-downtime dual-key support.

Authentication

• Zero client-side trust. No tokens stored in localStorage or sessionStorage. No Firebase Client SDK. Sessions are server-side only.
• Mandatory MFA. Every account requires TOTP multi-factor authentication. No exceptions.
• Server-side sessions. Signed HttpOnly cookies with 30-minute idle timeout and 8-hour absolute maximum. CSRF protection via double-submit cookie pattern.
• Brute force protection. Account lockout after 5 failed attempts. IP-level rate limiting. Replay attack detection on TOTP codes.
• Backup codes. 8 single-use recovery codes, stored as SHA-256 hashes only.

Zero-Trust Service Architecture

• All services are private. Deployed with --ingress internal-and-cloud-load-balancing. Cloud Run rejects any request not originating from the load balancer.
• Layered access control. Cloud Run services use --ingress internal-and-cloud-load-balancing to reject all traffic not originating from the load balancer. The LB is the sole entry point, protected by Cloud Armor's deny-by-default WAF. Service-to-service calls within the platform use GCP identity tokens and HMAC-signed headers for authentication.
• HMAC-signed headers. Identity headers (X-User-ID, X-Tenant-ID) are signed with HMAC-SHA256. Backend services verify the signature before trusting the headers.
• Platform tenant resolution. Every request is resolved to a platform tenant via the Host header. Tenant context is injected by the gateway and cannot be spoofed.

Data Isolation

• Two-level tenancy. Platform tenants (your company) contain application tenants (your customers). Data isolation at every layer.
• Database isolation. All queries scoped by tenant_id. Parameterized SQL only — no string concatenation. Dedicated database instances available on Business and Enterprise plans.
• Document isolation. GCS storage paths enforce tenant boundaries: tenants/{tenant_id}/docs/{document_uuid}/. Cross-tenant access is impossible through the API.
• Session isolation. Tenant ID embedded in the signed session cookie. Cannot be modified by the client.

Audit & Compliance

• 7-year immutable audit logs. All security events exported to a GCS bucket with locked retention policy. Append-only writes. No admin override. Versioning enabled.
• Structured logging. Every request logged with user ID, tenant ID, request ID, method, path, status code, and duration. Distributed tracing via X-Request-ID across all services.
• PII redaction. Financial PII (SSNs, account numbers, card numbers) automatically redacted from all log output before it reaches the logging service.
• Document integrity. CRC32C checksum verification on upload confirmation and every download. Tampered documents are blocked and audited.
• Security Command Center. GCP Security Command Center (Standard) enabled for proactive misconfiguration detection.

Monitoring & Incident Response

• Uptime monitoring. Health checks on all services every 60 seconds with automated alerting.
• Security alerting. Alerts on 5xx error spikes, high latency, brute force attempts (20+ auth failures in 5 minutes), and database health issues.
• Incident response plan. Documented procedures for identification, containment, eradication, and recovery. Kill switch capability to disable all services within seconds.

Secret Management

• GCP Secret Manager. All application secrets stored in Secret Manager with per-secret IAM bindings (least privilege).
• Version-based rotation. Services read the latest two versions from the Secret Manager API for zero-downtime rotation. No manual _PREV secret management.
• Automated rotation. Cloud Scheduler triggers rotation every 90 days. New version is added, services pick it up on next request. Previous version remains valid for dual-key operations.

Automated Testing

• 190+ automated tests across all services. Run before every deployment — no code reaches production without passing all tests.
• CI/CD pipeline. GitHub Actions runs all backend tests (Node.js) and frontend tests (Vitest) on every push and pull request.

Reporting Security Issues

If you discover a security vulnerability, please report it responsibly to security@symlfy.com. We take all reports seriously and will respond within 48 hours.

Please do not publicly disclose vulnerabilities until we have had an opportunity to investigate and address them.