Security at SocZap

• In transit: all traffic is served over TLS 1.2 or higher with HSTS preload enabled (max-age=63072000; includeSubDomains; preload). HTTP requests are upgraded automatically.
• At rest: the production database and file storage are encrypted at the database layer by Supabase using AWS KMS-managed keys. Application-layer field-level encryption is not in place — Supabase, as our hosting provider, has database access.

Every customer-facing table enforces Row-Level Security (RLS) so an authenticated user can only read and write their own rows. Anonymous (unauthenticated) Data API access has been explicitly revoked on user-data tables. The questionnaires storage bucket is private; files are namespaced by user ID and access is mediated by short-lived signed URLs scoped to the requesting session.

• Email + password with a 12-character minimum and complexity requirements (lower, upper, digit, symbol).
• Passwords are hashed with bcrypt by Supabase Auth. They are never stored, logged, or transmitted in plaintext.
• Optional TOTP multi-factor authentication. Enroll under Settings → Security. Enforcement is per-user today; team-wide mandatory MFA is on the compliance roadmap below.
• Sessions use HTTP-only, secure cookies signed and rotated by Supabase Auth.

SocZap uses OpenAI’s standard chat completions API, server-side only, to extract questions from uploaded documents and to generate draft answers. This is the part of the system buyers ask about most often, so we describe it in detail.

• What we send to OpenAI: extracted questionnaire text, your security profile JSON, and up to twenty matched Q&A pairs from your answer vault. We do not send your email, password, payment information, or any other data outside the question-answering flow.
• Retention: per OpenAI’s API policy, your data is not used to train OpenAI models (the post-March 2023 default for API customers) and is retained by OpenAI for up to 30 days for abuse monitoring. We do not currently have a Zero Data Retention agreement with OpenAI; this is on our compliance roadmap below.
• Prompt-injection defense: uploaded text is sanitized for Unicode tag characters, zero-width characters, and known injection patterns before it reaches the model. Suspect questions are flagged in the review UI rather than silently rewritten.
• No logging of model output: generated answers may contain content from your questionnaire — we log token counts and finish reasons, never the response body.

Uploaded questionnaire files are deleted from our storage automatically 7 days after upload by a daily scheduled job. The job removes the source object from our private Supabase storage bucket and nulls the corresponding database reference. Your extracted questions, generated answers, and any edits you made to them remain in your account after the file is removed — only the original source file is purged.

You can also delete the source file on demand: a per-questionnaire API endpoint (DELETE /api/questionnaires/{id}/delete-file) is available today, and an in-product button will be wired to it in the coming weeks. Both paths are idempotent and ownership-checked.

After the source file is removed, the in-product re-export to the original file format (XLSX, DOCX, or PDF) is no longer possible — answers can still be reviewed, edited, and copied to clipboard, and a fresh upload of the source file restores file-format export. This trade-off keeps our default storage footprint small and our deletion promise concrete rather than aspirational.

To fully delete your account (cascading through profile, security profile, questionnaires, vault entries, and any remaining storage objects), use Settings → Danger zone; see the “Account deletion” section below.

Uploaded questionnaires are validated by three independent checks before any content is parsed or sent to a model.

• Extension whitelist: only .pdf, .docx, .xlsx, and .txt are accepted.
• MIME type whitelist: the browser-reported MIME type must match a known-good value for the chosen extension.
• Magic-byte signature: the first bytes of the file must match the format header (%PDF for PDF, PK\x03\x04 ZIP header for DOCX/XLSX). This catches an attacker renaming a file to a permitted extension.
• Size limit: 10 MB per file, enforced server-side. Oversize uploads return 413.
• Rate-limited: a single user account can submit at most 10 uploads per hour (see Rate Limiting below).

The XLSX parser we use is a maintained community fork (@e965/xlsx) chosen specifically to address prototype-pollution and ReDoS advisories in the original xlsx package.

SocZap ships the following HTTP security headers globally on every route:

The X-Powered-By header is disabled. All API routes verify the authenticated user on every request (no reliance on middleware alone). Stripe webhooks verify HMAC signatures against the raw request body before any side effects, and webhook deliveries are idempotency-checked against an event-ID dedupe table.

Sensitive endpoints are rate-limited per user account using Upstash Redis. Limits are enforced server-side and fail-closed: if rate-limit configuration is missing in production, the application refuses to start rather than silently allowing unlimited requests.

We use a small set of trusted vendors to operate the service. The full list, their purpose, and the data-transfer mechanisms used is at /sub-processors. We commit to notify customers at least 30 days before adding a new sub-processor — subscribe by emailing security@soczap.com.

We capture application errors via Sentry and product analytics via PostHog. Both vendors handle data per their published policies (see /sub-processors). Sentry payloads pass through a beforeSend hook that scrubs known PII fields, and we explicitly avoid logging model output, response bodies, or vault contents. Rate-limit rejections and authentication failures are logged with user identifiers but never with credentials.

You can permanently delete your account at any time from Settings → Danger zone. Deletion cascades through your profile, security profile, questionnaires, answer-vault entries, and uploaded files; the Supabase Auth user record is removed in the same flow. Residual copies in our hosting provider’s encrypted database backups are purged consistent with their point-in-time-recovery window.

If you believe you have found a security issue, please report it privately to security@soczap.com. We acknowledge reports within 2 business days. Machine-readable contact information is published at /.well-known/security.txt.

We commit to good-faith handling: we will not take legal action against researchers who follow responsible-disclosure practice (no data exfiltration, no service degradation, reasonable time for us to remediate).

If we confirm a security incident affecting customer data, we will notify affected customers within 72 hours of confirmation, by email to the account address on file. Notifications include what we know, what we are doing about it, and what we recommend you do. This window mirrors GDPR Article 33 and gives a solo-operator team time to triage, confirm scope, and write an accurate notice rather than rush an incomplete one.

SocZap is an early-stage product. We have published this page in the spirit of being honest about both what we have done and what we have not yet done.

Controls in place today

• Row-Level Security on every user-data table with explicit Data API grants
• Optional TOTP MFA, 12-character password minimum, bcrypt hashing
• TLS 1.2+ in transit, AES-256 at the database layer
• Uploaded files auto-deleted 7 days after upload; on-demand purge endpoint available
• Published sub-processor list and signable Data Processing Addendum
• Vulnerability disclosure program and 72-hour breach notification commitment
• Application-layer rate limiting on sensitive endpoints, fail-closed in production
• Sentry beforeSend PII scrubbing; no logging of model output
• Database-level write protection on billing fields (users cannot self-promote plans)
• Extension + MIME + magic-byte validation on all file uploads
• Custom XLSX parser fork to address known prototype-pollution and ReDoS advisories

Not in place today (honest gaps)

• No SOC 2 or ISO 27001 certification. Our controls are modeled on the SOC 2 Common Criteria, but we have not engaged an auditor.
• No third-party penetration test on record. We can share our internal control list under NDA.
• No mandatory MFA enforcement (currently per-user opt-in).
• No SSO or OAuth providers.
• No Zero Data Retention agreement with OpenAI (we rely on their standard API policy described above).
• No automated SAST or dependency scanning in CI today.
• No application-layer field-level encryption — database-level encryption only.

Roadmap

We will pursue SOC 2 Type I when an enterprise customer requires it as a condition of purchase, with a target of completing Type II within twelve months of that engagement. Third-party penetration testing, mandatory MFA, and OpenAI Zero Data Retention will be addressed before the audit window opens. If your team has specific requirements you’d like to discuss against this roadmap, email security@soczap.com.

A signable Data Processing Addendum is available on request — see /dpa.