Security at PostQ
We build security infrastructure — so our own security practices must be exemplary. Here’s how we protect your data and systems.
Scanner Data & Privacy
The free domain scanner inspects only the public metadata exposed during a normal TLS handshake. We never ask for, upload, or store private keys.
No private key upload required
External scans read certificate metadata, TLS versions, ciphers, and the negotiated key exchange. We only inspect public metadata unless an authenticated integration (cloud KMS, Kubernetes) is explicitly configured, and even then we read key metadata and usage — never private key material.
What we collect during a scan
The scanned domain, certificate chain fields (subject, issuer, algorithms, expiry, fingerprints), TLS version support, negotiated cipher and key exchange, and the derived findings and readiness score. The basic external scan requires no signup.
SSRF protections
The scanner resolves the target and refuses to connect to private, loopback, link-local, or otherwise reserved addresses. Only public hosts on port 443 are scanned.
Storage & deletion
Shareable report links encode the scanned domain so reports can be re-generated on demand. Saved scan history (paid plans) is scoped to your organization and can be deleted at any time; see Data Handling below.
Infrastructure Security
Encryption in Transit
Customer-facing production origins enforce HTTPS. TLS protocol and hybrid key-exchange availability depend on the deployed edge provider and are continuously observable with the same PostQ scanner customers use.
Encryption at Rest
The managed database and storage providers encrypt their volumes at rest. Vault additionally seals PostQ-managed private material with per-key AES-256-GCM data keys that can be wrapped by a customer-owned AWS, Azure, or Google Cloud KMS key.
Service Boundaries
Public APIs expose only documented routes with scoped authentication, rate limits, request-size limits, and readiness checks. Enclave RPC defaults to loopback and refuses a remote listener unless TLS and bearer authentication are explicitly configured.
Application Security
Authentication
Dashboard identity and session lifecycle are managed by Supabase Auth. API integrations use scoped PostQ keys whose plaintext is shown once and whose SHA-256 digest, expiry, revocation state, and last-use timestamp are stored server-side.
Authorization
Row-level security (RLS) policies and explicit organization filters enforce tenant isolation. Organization roles are owner, admin, member, and viewer; sensitive settings changes are restricted to owners and admins for session-authenticated users.
API Security
Privileged API endpoints enforce scoped authentication and global per-key/IP rate limits; selected public routes have tighter limits. Zod schemas constrain request shapes, CORS uses an origin allow-list, logs redact credentials, and every response includes a request ID.
Data Handling
Scan Data Isolation
Scan results are scoped to your organization and are never shared with other users or organizations. We do not use customer data to train models or for any purpose beyond providing the Service.
Data Residency
PostQ infrastructure is hosted in the United States. Enterprise customers can request specific data residency configurations.
Data Deletion
Policies and supported organization settings can be removed in-product. Other deletion or export requests are handled through support while self-service lifecycle controls are expanded. Contracted retention and backup terms take precedence for enterprise customers.
Development Practices
- Automated tests, type checks, builds, dependency audits, and CodeQL run in CI
- Release artifacts include checksums; scanner images add SBOM, provenance, and keyless signatures
- Secrets are never committed to version control — managed via environment variables and vault systems
- We follow the principle of least privilege for all system access
- Production deployments are automated with immutable infrastructure
Standards & Compliance
Reporting a Vulnerability
If you discover a security vulnerability in PostQ, please report it responsibly. Email security@postq.dev with a description of the issue and safe reproduction steps. Do not include live credentials or customer data.
We do not pursue legal action against researchers who report vulnerabilities in good faith and follow responsible disclosure practices.
Questions about our security?
Reach out to our security team for questions, reports, or enterprise compliance documentation.