Security Posture

1. Application and Transport Security

• HTTPS with strict transport security (HSTS preload enabled).
• Security headers configured globally, including  `X-Frame-Options`, `X-Content-Type-Options`,  `Referrer-Policy`, and `Permissions-Policy`.
• Content Security Policy (CSP) restrictions are applied to script, style, image, and connection sources.

2. API Input and Access Controls

• APIs validate required fields, maximum lengths, and allowed values using centralized schema validation (Zod where applicable).
• Email format validation is enforced for support and account intake.
• Access tokens and session identifiers are validated before processing.
• External service URLs are restricted to valid HTTPS URLs to reduce SSRF risk.

3. Authentication and Secrets Handling

• OAuth access tokens, refresh tokens, webhook URLs, and API keys are encrypted at rest using AES-256-GCM where applicable.
• Session tokens are hashed (SHA-256) before database storage; raw values are never persisted.
• Service integration keys are loaded from environment variables and not hardcoded.
• Webhook payloads from GitHub, Stripe, and other providers are verified via HMAC-SHA256 signatures with constant-time comparison.

4. Data Isolation and Access Control

• PostgreSQL Row-Level Security (RLS) policies ensure users can only access their own data.
• Database queries are parameterized throughout to prevent SQL injection.
• Account deletion triggers full anonymization of identifiable data.

5. AI Security Controls

• All AI inference is routed through the Vercel AI Gateway with Zero Data Retention (ZDR) models exclusively — a company-wide policy.
• AI endpoints require authenticated sessions and are subject to rate limiting.
• Prompt injection mitigations are in place: input escaping, structured output schema validation, and output sanitization.
• AI outputs are validated against strict schemas before being stored or returned to users. Invalid responses trigger deterministic fallback behavior.
• No source code, file contents, or raw user PII is ever sent to AI model providers.

6. Mobile Application Security

• Our Android apps have no CHKDSK Labs backend and no CHKDSK Labs accounts. There is no server to breach and no credential of ours for an attacker to steal.
• Signing material is never committed. Upload keystores and their passwords are read from an untracked local file on a workstation or from environment variables on CI, and release builds are distributed through Google Play's signing infrastructure.
• Release builds ship minified and resource-shrunk, and debug builds carry a distinct application ID so a test build can never impersonate the published app.
• Permissions are kept to the minimum the app actually needs. Our games request no runtime permission at all. CastBlast requests the microphone, because broadcasting your voice is what it does, and can capture other apps' audio only through Android's media projection consent dialog; it requests no location, camera, contacts, or external storage, and uses the document picker rather than a storage permission to open files.
• Audio is never persisted. CastBlast holds captured audio in memory only as long as it takes to reach a speaker, writes no recording to disk, and has no upload path of any kind.
• Where an app serves audio over the local network, the server binds to the local interface only, is never exposed to the internet, runs only while a broadcast is live, and serves nothing but the stream itself at a per-device address.
• Where an app offers optional platform features, authentication is delegated entirely to Google Play Games Services, which is bound to the app's signing certificate. The app handles no passwords and stores no tokens of its own.
• Where an app is ad-supported, advertising SDKs are not initialised until the Google User Messaging Platform consent flow has been resolved, so no advertising identifier is shared before the player has answered it. Our paid apps contain no advertising SDK and do not request the advertising ID.
• Saved data is written to app-private storage. Any cloud copy lives in the player's own Google account via Play Games Saved Games, not on infrastructure we operate.

7. Logging and Privacy Safeguards

• Error responses are generalized for end users and avoid exposing internal stack traces.
• Browser cookie consent preferences are stored locally and not sent to CHKDSK Labs servers.
• APIs use bounded input sizes to reduce abuse and accidental over-collection.
• Structured audit logging captures security-sensitive and compliance-sensitive actions where applicable.

8. Certifications and Assurance Scope

CHKDSK Labs does not currently claim a formal SOC 2 or ISO 27001 certification. Security posture is maintained through implemented controls, internal reviews, and periodic updates to these disclosures.

9. Vulnerability Reporting

Report vulnerabilities to  jay@chkdsklabs.io with reproduction details. We prioritize confirmed security issues and respond as quickly as possible.

Related Documentation

• Privacy Policy
• Terms & Conditions
• Third-Party Services
• Data Processing Agreement