Security

This page describes the security properties of the running system, in the terms a platform review or a customer’s security questionnaire asks for. It describes what is implemented, not what is planned; the open points are listed at the end.

Authentication

• Passwords are stored as salted PBKDF2-SHA256 derivations with a per-user random salt. The work factor is recorded with each hash so it can be raised later without invalidating existing passwords.
• A sign-in always performs the full derivation, including for addresses that do not exist, so response timing cannot be used to enumerate users.
• Failed sign-in attempts are recorded and rate limited.
• Session cookies carry a random 256-bit token. The database stores only its SHA-256 hash, so a database copy cannot be used to resume a session.
• Session cookies are HttpOnly, Secure and SameSite=Lax, and expire server-side. Expired sessions are removed by a scheduled job.

Integration credentials

• Provider credentials — including the TikTok Shop app secret and refresh token — are encrypted with AES-GCM before they are written. The encryption key lives in the runtime’s secret store, never in the database.
• No API response returns a credential value. The interface shows a non-reversible hint (the last four characters); a credential can be replaced but never read back.
• A database dump alone is therefore not sufficient to use a customer’s TikTok authorisation.
• Access tokens are refreshed by a scheduled job before they expire, and every attempt records its outcome — including failure and “not configured” — so a silently dead integration is visible rather than discovered a week later.

Workspace isolation

• Every request resolves to exactly one workspace, and every database query is scoped by that workspace identifier.
• Switching workspaces is an explicit, server-validated action against the caller’s own memberships.
• Cross-workspace access is covered by automated tests that run against the deployed environment, not only locally.

Platform limits

Outreach quotas are enforced on the server, not in the browser. The counter is incremented with a single conditional database write, so simultaneous requests cannot both consume the last remaining slot. This is verified live: ten concurrent sends to the same creator consume exactly one slot.

Transport and headers

• HTTPS only, with HSTS at the edge.
• X-Content-Type-Options: nosniff and a strict Referrer-Policy on every response.
• Application surfaces are marked noindex; only the public marketing pages are indexable.
• State-changing API requests are rejected when they originate from another origin.

Hosting

Socify runs on Cloudflare Workers with Cloudflare D1 as its database. There are no long-lived servers to patch and no customer data on developer machines. State your configured D1 storage region here.

Reporting a vulnerability

Please report security issues to SECURITY@SOCIFY.CC. We will acknowledge within three business days. Please do not publish details before we have had a reasonable opportunity to fix the issue, and please do not access data that is not yours while testing.

Open points, stated plainly

• No verified email channel yet, therefore no automated password reset, email verification or user invitations.
• Roles exist and are enforced for credential access, but are not yet enforced across every endpoint.
• No third-party penetration test has been performed. Update when one has.
• No formal certification (ISO 27001, SOC 2) is claimed or held.