Security

この文書は英語で公開されており、英語版が適用されます。

This is a draft for legal and security review, not a finished public document. It describes the security practices the product is designed to follow. It must be checked against the running system, and reviewed by counsel, before it is published. Do not claim any control below that is not actually in place at launch.

Last updated: 2026-09-20 (draft; the published date is set when it is approved)

1. Purpose

This page tells customers how Universe Help protects their data. It is one of the five legal and trust documents linked from the public website (Privacy Policy, Terms of Service, DPA, Security Documentation, NDA).

2. Security approach

The backend decides. Every request is authenticated, authorized, validated and checked against the customer's plan on the server. Web and mobile screens hide what a user cannot do, but hiding is never the only protection.
Security is built into each feature, not added at the end.
Least privilege. People see only the platforms, data and actions their Owner has granted them.

3. Data isolation

Every workspace's data is separated from every other workspace's.
The database enforces Row Level Security, and the backend independently checks workspace membership, role and platform permission on every action.
AI memory is scoped per workspace and never shared between workspaces.
Cross-tenant access is tested as part of security testing.

4. Authentication and access control

Sign-in uses a managed authentication service. Passwords are hashed and never stored in plain text.
Sessions expire, and can be ended remotely. Device limits are enforced per plan.
Owners can log out any collaborator or all collaborators, and block a collaborator. A blocked collaborator is logged out immediately and cannot sign in until unblocked.
Permissions are re-checked on every action, so a revoked permission takes effect immediately.
Administrator access is separate from customer access: it uses a separate subdomain, requires multi-factor authentication on every sign-in, and every Admin action is audit-logged.

5. Protecting credentials and connected accounts

Access tokens for connected social accounts are encrypted at rest and are used only on the server. They are never sent to browsers or mobile apps and are never written to logs.
Tokens are revoked when an account is disconnected.
Secrets (API keys and similar) are held only in server-side secret stores, are separate for development, staging and production, and are never placed in client code or source control.

6. Data in transit and at rest

All traffic uses HTTPS/TLS, with a web application firewall and DDoS protection at the network edge.
Sensitive fields are encrypted at rest. Uploaded media is stored in private object storage and served through short-lived signed links.
Card numbers are never stored by us. Payments are handled by our billing provider and its payment processor.

7. Application security

The product is designed to defend against:

SQL injection (parameterized queries and validated input only).
Cross-site scripting and unsafe rich content (output encoding and allow-list sanitizing, including for blog content).
Template injection, server-side request forgery, and open redirects (allow-lists and network restrictions on outbound requests, including the SEO crawler).
Regular-expression and resource-exhaustion attacks (limits on input size, crawl size, concurrency, and time).
Replay and duplicate submissions (idempotency keys and expiring request identifiers).
Malicious uploads (file type, size and signature checks; executable files rejected).
Brute force and abuse (rate limiting at the edge, in the application, and per user, workspace and endpoint).
Cross-origin abuse (strict CORS and security headers).

Input is validated in the browser or app for usability and again on the server for security.

8. AI and data

Only the content needed for a requested AI action is sent to our AI provider.
We do not put secrets, passwords, tokens or payment details into AI memory.
AI output is validated before it is stored or used, and the customer stays in control: nothing is published without approval unless the Owner turns on auto-publish for that platform.

9. Monitoring, logging and audit

Errors and performance are monitored, and alerts are raised for failures.
Activity logs record who did what, when and on which platform. Audit logs for sensitive changes are written together with the change itself.
Logs and error reports must not contain passwords, tokens or payment details.

10. Availability, backups and recovery

Background work runs on separate, restartable worker processes with retries.
The database is backed up automatically each day with point-in-time recovery. [Recovery point and recovery time targets are not set yet; add them here before publishing (PRD.md section 0.5).]
Deletions are soft deletes, so accidental deletions can be recovered.

11. Data retention

Lead comments and messages are anonymized after 90 days (aggregate score and classification are kept). Leads the Owner marks "converted" can be kept longer.
After a plan expires, workspace data is locked for 90 days and then soft-deleted unless the customer buys a plan again.
Export and deletion requests are handled through the support email within 30 days.

12. Vulnerability reporting and incident response

Report suspected vulnerabilities to satendrapatel2468@gmail.com. We will acknowledge reports and will not take action against good-faith researchers who follow responsible disclosure. [Counsel to review this statement.]
If a personal data breach affects a customer, we notify the customer without undue delay and within 72 hours of becoming aware, as set out in the DPA.

13. Development practices

Code changes go through pull requests, automated checks (lint, unit tests, build), a staging environment with end-to-end tests, and only then production.
Development, staging and production are separate environments with separate credentials.
Security testing (authentication bypass, permission bypass, cross-tenant access, injection, rate limits, uploads, webhooks) is part of the release process.

14. Compliance

We design to the GDPR, CCPA/CPRA and India's DPDP Act as a worldwide baseline. We are not currently certified to any third-party standard. [Update only if that changes.]

Flags for review:

Every statement here is a design intention drawn from the product documents. Before publishing, the operator must verify each one against the running system.
Section 10 recovery targets are author defaults (PRD.md section 0.5) and must be confirmed.
Section 12 needs a real security contact address, and counsel must review the safe-harbor wording.
Do not add uptime guarantees, certifications, or "military-grade" style claims.