Security

How accounts are protected

• Passwords are hashed with scrypt. We store a scrypt hash with a random salt for every password, using work factors at or above the current OWASP guidance. Your password itself is never written down anywhere, so we cannot read it, tell it to you, or hand it over.
• Password checks run in constant time. A wrong password takes the same time as a right one, so nobody can narrow a guess down by timing the response.
• Sign in is rate limited. Repeated attempts from the same address are refused for a period. That makes guessing a password by brute force impractical.
• Sign in requests must come from Cineva. A form on another site cannot post your credentials to us.
• Failures do not leak. A failed sign in never says whether the email exists, only that the combination was wrong.
• You can use Google instead of a password. If you do, Google verifies you and we never handle a password at all. We do not receive your Google password and we do not read your Google account.

Sessions and cookies

When you sign in, we set one cookie holding a signed token. The signature is checked on every request, so a tampered or forged token is rejected rather than trusted.

The cookie is httpOnly, which means scripts running in your browser cannot read it. It is marked secure in production, so it only travels over an encrypted connection. It is set to lax same site, which blocks the common cross site request forgery route. It expires on a timer, at which point you sign in again.

The whole site and the whole app are served over TLS. There is no unencrypted route into Cineva.

Card details never reach us

Stripe handles payment. Your card number is entered on infrastructure Stripe controls and it never touches a Cineva server, so a breach here could not expose it. We hold what you bought, what you paid and when, which is what the receipts and the refunds are built from.

That is a real reduction in risk rather than a claim about our own engineering. The safest way to hold card data is to never hold it.

Where your data sits

The app runs on Vercel. Accounts, projects and generated output live in Supabase. Payments live at Stripe. Model providers receive the material for a run and nothing else. All of it is in the United States, and the full list of who gets what is in the privacy policy.

Access to production data is limited to the operator, and there is no shared team account to leak. Secrets live in environment variables at the host, never in the code and never in the browser.

What we do not claim

Everything above is a control that exists today. Here is what does not exist, stated plainly so you can weigh it.

• We have no SOC 2 report, no ISO 27001 certificate, and no other security certification.
• We have not had a third party security audit.
• We have not had a penetration test.
• We do not make a guarantee about encryption at rest. Our hosting providers describe their own storage protections in their own documentation, and we are not going to restate their claims as ours.
• There is no bug bounty program and no security team. There is one person who reads the email.

If any of that changes, this page changes with it. If a page like this ever claims a certification, ask to see it.

Your part

• Use a password you use nowhere else. Credential stuffing, where passwords leaked from another site are tried here, is the single most likely way an account gets taken.
• Keep the email address on your account secure, because it is the route back into the account.
• One account, one person. Do not share sign in details.
• Think before you paste. A script you have not been cleared to share is safest in the place it already lives.

If you think someone else has access to your account, email hello@cineva.io and we will help you lock it down.

Reporting a vulnerability

Email hello@cineva.io with security in the subject line. Tell us what you found, how to reproduce it, and what an attacker could do with it. A short proof of concept helps more than a scanner report.

We acknowledge within 5 business days and tell you what we plan to do. Serious issues get fixed first and everything else gets a date. We will credit you when the fix ships if you want that, and we will keep your name out of it if you do not. There is no cash bounty, and we are not going to pretend otherwise.

Rules for security research

Test against your own account only. Stop as soon as you have confirmed a problem, and tell us before you tell anyone else.

• Do not access, modify or download data belonging to another user.
• Do not run load tests, denial of service tests or automated scanners that degrade the service for other people.
• Do not use social engineering against the operator or a vendor.
• Do not publish a finding until it is fixed, or until 90 days have passed and we have gone quiet.

Stay inside those rules and we will treat your testing as authorized research, we will not pursue a claim over it, and we will work with you on the fix. Step outside them and the acceptable use policy applies like it does to anyone else.

If something goes wrong

No service is perfectly secure, and this one is smaller than most. If a breach ever puts your data at risk, we will tell you by email without unnecessary delay, say what happened and what was exposed, tell you what to do about it, and notify the authorities that state breach notification law requires us to notify.

You will hear it from us, not from a rumour. Keep your own copies of work you cannot afford to lose, whatever any service promises you.