Compliance

What follows is what is actually built, so you can judge the parts that matter to you rather than take a status table on trust. The last section lists what we do not have — a compliance page that only lists strengths is not a compliance page.

Encryption you don't have to trust us on

• Content created in the web app or through the API is encrypted in the client, before the request — AES-256-GCM under a per-share content key. The key travels in the share link's URL fragment, which browsers never transmit, so it does not reach our servers, our logs, or our database.
• The API enforces this rather than encouraging it: a create must declare e2ee-aes256-gcm and carry ciphertext, and a plaintext payload is rejected.
• What we store for a client-encrypted share is ciphertext plus a SHA-256 hash of an access token. When a share is passcode-protected, the passcode is replaced on the wire by a one-way verifier — we can count failed attempts while holding nothing that helps us decrypt.
• Credentials sent through the Slack app are encrypted on our servers instead, with keys in a managed key service. We can decrypt those. We say so plainly rather than implying otherwise.
• The wire and crypto formats are pinned by a normative conformance-vector suite that every official SDK — Python, Node, Go, Rust — must reproduce byte for byte in its own test run. A client that drifts from the spec fails its build rather than silently producing content nobody can read back.

The share access log

• Every open of a share writes an access-log row: timestamp, IP, platform, user agent, the accessing account where there is one, and whether a passcode attempt failed.
• Access logs survive the share. When a share expires its record keeps the original identifier, so the access history stays intact and readable after the content itself is gone.
• Owners can read the history per share, or export a whole account's log over a date range. The export is scoped to the caller — you get your own trail, never anyone else's.
• The retention window is enforced server-side: the API clamps the requested start date to your plan's window and reports the range it actually applied, so a modified client cannot reach further back than the plan allows. Exports are capped per request and flag themselves when truncated.

Deletion that is a real delete

• Expiry is a hard DELETE, not a hidden flag. There is no soft-delete column on the share record, so an expired share's payload is gone from the database rather than filtered out of queries.
• The expiry sweep runs hourly in production, and also immediately when an expired share is opened.
• What we retain after expiry is a metadata record — title, settings, whether a passcode was set — deliberately built as an explicit list of fields so that secrets cannot be added to it by accident. The encrypted payload, the passcode, the passcode verifier and the access-token hash are all excluded.

Where your data lives

• Single region: US East (N. Virginia). All databases and object storage are provisioned there and nowhere else. We do not currently offer alternate regions; if you need one, that is a conversation, not a setting.
• The production database is encrypted at rest under a customer master key in AWS KMS, with 7-day automated backup retention.
• Backend secrets live in AWS Secrets Manager and are fetched at runtime. Production functions carry only the identifier of the secret in their configuration — no database credentials, no API keys, no signing material in environment variables.

Connections

• The web app, share and paste hosts require TLS 1.2 or better — TLS 1.0 and 1.1 handshakes are refused — and send HSTS with includeSubDomains and preload.
• Every page ships a Content Security Policy with object-src 'none', base-uri 'self', form-action 'self' and a restrictive frame-ancestors, plus X-Content-Type-Options: nosniff.

Controls you can turn on

These are account controls available to you today, not descriptions of our internal practice.

• Multi-factor authentication is available on every account: an emailed one-time code, an authenticator app (TOTP), or SMS. It is optional rather than mandatory — you choose whether to enable it, and we do not claim it is enforced across all accounts.
• Per-share limits. A share can require a passcode, expire at a chosen time, cap how many times it may be viewed, and be restricted to particular email domains or source addresses.
• Scoped API keys. A key carries only the scopes you grant, matched exactly with no hierarchy and no wildcards, and it cannot mint or widen another key. Key management stays on the session-authenticated app surface for that reason.
• Custody is opt-in for API-created shares. By default a share created through the API is readable only by whoever holds the link — not from your own dashboard, and not by us. Storing a recoverable copy is a deliberate choice you make per share.
• Signed webhooks. Deliveries carry an HMAC-SHA256 signature over the timestamp and raw body, with a per-endpoint secret that is randomly generated and sealed. Rotation runs a 24-hour window where both the old and new secrets sign every delivery, so a receiver can be updated without dropping events.

What we do not have yet

• No SOC 2 report, ISO certificate, HIPAA BAA or third-party penetration-test report. If a vendor questionnaire asks for one, the honest answer is that we have none.
• No published SLA or uptime measurement. The production database is single-AZ.
• Internal access controls are being rebuilt. Administrative access to our cloud account is not yet behind enforced MFA or just-in-time role assumption, and account-level API audit logging is not yet enabled. This is our top-priority security work, and this page will be updated when it lands rather than before.
• GDPR data-subject requests are handled manually. Mail security@credenshare.io. We have no automated export or erasure endpoint, and we do not quote a turnaround we cannot yet measure.

Reporting security issues

If you discover a vulnerability in CredenShare, please report it responsibly to security@credenshare.io. We will confirm receipt and keep you updated while we work on it.