Skip to main content
Your saved knowledge should feel retrievable and useful — and genuinely difficult to misuse. Cachd is built around explicit user action: you sign in through supported providers, connect only the accounts you trust, import only the content you choose, and handle billing outside the product entirely through Stripe. This page summarizes the controls in place today, the honest boundaries of what Cachd does and does not claim, and how to reach the team if you discover a security issue.

​
What’s in place today

Authentication

Accounts are authenticated through Google OAuth, with server-side session checks enforced at every protected route and API. Native email-and-password login is disabled.

Scoped Permissions

All third-party connections use the narrowest permission scope required. Google Photos import uses a read-only picker scope. You control which accounts are connected and can revoke access at any time.

Validated Requests

All requests are validated before any write operation runs. Missing or invalid tokens are rejected outright, and errors are handled consistently across the service.

Payment Security

Checkout, billing portal management, and subscription webhooks all run through Stripe. Cachd stores your billing state and Stripe identifiers — never raw card numbers.

Transport Security

The web application ships with Strict-Transport-Security (HSTS with preload and subdomain coverage), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy headers applied globally.

Log Sanitization

Sensitive fields — tokens, secrets, cookies, authorization headers, emails, phone numbers, IP addresses, and card numbers — are redacted before structured logs are emitted. Console logging is disabled in production.

​
Authentication & sessions

Cachd accounts are authenticated exclusively through supported identity providers. There is no native email-and-password login path.
  • Google sign-in is enabled through server-side session management.
  • Server-side session checks are enforced at every protected route and API endpoint — client-side state alone is never trusted.
  • Trusted origins and multi-session support are configured at the auth layer, so you can stay signed in across devices without weakening session integrity.
When you sign in, a server-managed session is created. That session is validated on every subsequent request to a protected resource, ensuring that expired or revoked sessions cannot be replayed.

​
Connected account permissions

Every third-party connection in Cachd uses the narrowest permission scope available for the task.
  • Google Photos import requests a read-only picker scope (photospicker.mediaitems.readonly) that covers only the items you explicitly select in the picker. Cachd cannot browse your entire library.
  • Import routes require either an authenticated session or an explicit user-scoped ingest token. There is no unauthenticated import path.
  • Cachd advises you to connect only accounts you trust and to review the permissions you have granted at any time from Settings > Connected Accounts.
You can revoke Cachd’s access to any connected account from within the third-party service’s own permissions settings — for Google, that is myaccount.google.com/permissions.

​
Payment security

Billing is handled entirely through Stripe rather than Cachd’s own UI or database models.
  • Checkout sessions, billing portal access, and subscription webhooks are all Stripe-managed flows.
  • Cachd never stores raw card numbers. The only payment-related data Cachd holds is your subscription state, plan tier, and Stripe customer and subscription identifiers.
  • Payment configuration is protected by required server-side environment secrets and is never exposed to the client.

​
Reporting a security issue

If you discover a vulnerability, unexpected data exposure, or risky behavior, please report it directly. Send a security report → Include in your report:
  • A clear description of the issue and the affected URL, route, or workflow.
  • Steps to reproduce, any proof-of-concept details, and the likely impact if the issue is real.
  • Your contact information so the team can follow up while investigating.
Good-faith boundaries:
  • Please avoid accessing data that does not belong to you, degrading service availability, or running destructive tests against production.
  • Cachd does not currently advertise a public bug bounty program or a formal coordinated-disclosure policy.
  • Reports submitted in good faith will be reviewed promptly. The team will follow up on actionable findings.

​
What Cachd does not claim

Cachd already includes meaningful baseline controls — provider-backed auth, hardened headers, typed request validation, scoped import permissions, tokenized browser ingestion, and log sanitization. But this page is not a claim of enterprise certification or zero risk.
No SOC 2 or ISO 27001 certification. Cachd has not undergone formal third-party security audits or achieved compliance certifications. If and when those programs exist, they will be documented explicitly.
No public bug bounty program. There is currently no formal bounty or coordinated-disclosure program. Good-faith reports are welcome, but no financial reward is implied.
No absolute guarantee of security. No internet service can promise zero risk. This page describes current controls — not guarantees about future resilience against all possible threats.
This page describes the security controls currently in place. For procurement security questions, architecture reviews, or data-processing clarifications, contact support@cachd.app directly with the scope of your review.