Security

• Collect and retain only data needed to provide and protect the service.
• Authenticate every private job, media, download, and billing action server-side.
• Keep original media and generated outputs private by default.
• Keep provider credentials out of browser code, URLs, analytics, and logs.
• Limit service and staff access according to role and operational need.
• Design processing jobs to fail safely, recover cleanly, and leave an audit trail.

Production accounts should use verified email, protected password storage, secure HTTP-only session cookies, rate limiting shared across service instances, short session requirements for sensitive actions, and server-side authorization in every protected handler.

Browser-supplied ownership, plan, quota, amount, and subscription status are never treated as authoritative. Free-credit reservation and refunds must be transactional so parallel requests cannot spend the same credit.

Uploaded media should use random server-controlled object keys in private storage. Upload and download access should rely on short-lived scoped links. File name and browser MIME type are not trusted; CUTKEEP validates size, container, streams, duration, resolution, and codec before work.

Video work is isolated in a background worker rather than tied to a web request. Temporary source and render files are removed after transfer, and a restarted worker must be able to resume safely without exposing another user's data. FFmpeg arguments and paths must be constructed to prevent command or path injection.

Razorpay handles card, bank, and UPI credentials. CUTKEEP verifies checkout signatures server-side and validates webhooks against the exact raw request body. Webhook event identifiers are recorded uniquely to prevent duplicate processing, and out-of-order events are reconciled against current provider state.

Payment secrets, webhook secrets, database credentials, storage credentials, Groq keys, Jev keys, email credentials, and authentication secrets are server-only. Production and test credentials are separated, access is least-privileged, and exposed or development-shared credentials must be rotated before launch.

CUTKEEP uses encrypted transport, private service networking, encrypted storage where supported, production access controls, health monitoring, dependency updates, structured log redaction, backups, and incident response procedures. Covered security logs are maintained in accordance with applicable requirements, including CERT-In directions where they apply.

Report a suspected vulnerability through the security or support contact on the Contact page. Include a clear description, affected URL or component, reproduction steps, and impact. Do not include customer media or personal data in an initial report.

Act in good faith: avoid privacy violations, data destruction, service disruption, social engineering, automated high-volume scanning, and accessing more data than needed to demonstrate the issue. Allow reasonable time to investigate before public disclosure. This is not a bug-bounty promise unless a separate programme expressly says so.

CUTKEEP maintains a process to contain, investigate, document, and remediate security incidents. Where required, affected users and authorities will be notified within applicable timelines. Covered incidents may require reporting to CERT-In within six hours of noticing them under the current directions.