What is protected, and what is not yet.

Payments

Card details never reach a Vessim server. Checkout hands off to Stripe, which returns a token; the token is what we store, and it cannot be used anywhere but our own account. There is no database table of card numbers to breach, and if you asked us to produce your card number we could not do it.

Transport and storage

Everything is served over TLS 1.3 with HSTS, so a downgrade to plain HTTP is refused by the browser rather than permitted quietly. A strict Content-Security-Policy restricts which origins can execute script on the page, which is the control that turns most injected-script attacks into a blocked request.

Data at rest — the account record, addresses, prompts, orders — is encrypted by the database platform. Design files sit in object storage behind signed, expiring URLs rather than at a guessable public path.

Accounts

Sign-in is handled by Supabase Auth. Passwords are hashed with a modern algorithm and are never stored or logged in a readable form. Sessions are held in an HTTP-only, same-site cookie, so page script cannot read the token even if script were injected.

Email sign-in links are single-use and short-lived. Rate limiting applies to sign-in, to password reset and to generation, which also stops the studio from being used as a free text-to-image endpoint.

Who can see your data internally

Access to production data is limited to the people who operate the service, and it is used to answer support requests, not to browse. Print partners receive only a name, an address and a design file — never an email address, a payment detail or a price. The full list of third parties and what each can see is on sub-processors.

What we have not done

This is the part most security pages leave out.

• No SOC 2 or ISO 27001. We hold no certification and have not been audited. A badge on this page would be a lie and an auditor would be the first to say so.
• No third-party penetration test yet. Scheduled, not done. This line will change when it is, with the date.
• No bug bounty. We cannot responsibly run a paid programme at this size. Reports are still welcome and still answered.
• No two-factor authentication yet. The single most requested item on the list and the next one being built.
• Pre-launch posture. Vessim is an early-stage company; the controls above are real, and the maturity around them — formal reviews, drills, an on-call rota — is not yet.

Reporting a vulnerability

Email security@makevessim.com. Include what you found, how to reproduce it and what you think the impact is. You will get a human reply within two business days and a fix or a plan within thirty.

We will not threaten you for a report made in good faith. Test only against your own account, do not access anyone else’s data, do not run denial-of-service traffic, and give us thirty days before publishing. Within those limits we will not pursue a claim, and we will credit you by name if you want it.

If something happens

If customer data is exposed, we will tell the people affected within 72 hours of becoming aware — what was taken, when, what we have done and what you should do. Notification will not wait for the investigation to finish, and it will not be worded to minimise. Regulators will be notified where the law requires it, and the incident will appear in the changelog.