Security

How Critiqa protects your data

A plain summary of our current security practices and how to report a problem. For the full legal detail, see our privacy policy.

Last reviewed: 7 October 2026

Data encryption

Passwords are hashed rather than stored in plain text. Credentials or tokens for supported connected marketing accounts are protected at rest, and sensitive email actions use signed tokens instead of exposing raw identifiers where the current workflow supports that pattern.

Critiqa uses encrypted HTTPS transport and secure session-cookie controls. Security headers, authentication controls and token handling are maintained as part of the application security configuration and are reviewed as the deployment architecture changes.

Vulnerability scanning schedule

Critiqa uses automated and manual security checks across source code, dependencies, secrets, authentication boundaries and deployed surfaces. The exact checks and execution environment can change as the CI and production architecture evolves.

Production-facing reviews include relevant transport and security headers, unauthenticated route protection, dependency and secret exposure, and infrastructure configuration. Release gates and security-sensitive changes remain subject to the current repository governance and deployment controls.

Penetration testing history

Critiqa has undergone application security reviews covering API routes, authentication and authorisation, common web vulnerabilities, infrastructure configuration, rate limiting and privilege boundaries. Additional security-hardening work and revalidation continue as the product changes.

Security findings are tracked, prioritised and remediated according to risk. This page is a summary of our practices, not a warranty that the Service is free from vulnerabilities.

Where your data lives

Core application and workspace data is stored in MongoDB Atlas. Uploaded media used by supported analysis and creative workflows is stored in Cloudflare R2 where the feature requires persistent media storage. The application runtime uses AWS App Runner in the eu-central-1 (Frankfurt) region, while the public marketing site may be served separately. Payment card details are handled by Stripe rather than stored by Critiqa, and transactional email is sent through Resend.

Incident response

Critiqa follows an incident-response process covering detection, containment, assessment, notification where required, recovery and review. Security and availability signals are monitored through the production observability stack, and backup or recovery controls are maintained for relevant data stores according to the current infrastructure configuration.

Report a vulnerability

If you believe you have found a security issue in Critiqa, email hello@critiqa.app with details and, if possible, steps to reproduce. This contact is also published at /.well-known/security.txt. Please give us reasonable time to investigate and fix an issue before disclosing it publicly.

Questions about how we handle your data?

Contact us