Security

1. Reporting a vulnerability

If you have found a security problem in any Aleph Developments property, please email us with "Security" in the subject line. Include the affected URL or endpoint, what you did, what happened, and why you think it is a problem. A minimal reproduction beats a scanner report by a wide margin.

We will acknowledge your report within five working days and tell you what we intend to do about it. Please give us ninety days before disclosing publicly, or less by agreement if the fix ships sooner. We are happy to credit you when we announce a fix if you would like that; say so in your email. We do not currently run a paid bug bounty, and it would be unfair to imply otherwise.

2. Safe harbour

If you make a good-faith effort to comply with this page while researching, we will not pursue or support any legal action against you for it, and we will treat your research as authorised. Good faith here means: you stop at the first proof that something is wrong rather than going further, you access only your own accounts and data, you do not degrade the service for anyone else, and you give us a reasonable chance to fix the issue before telling the world.

3. Out of scope

Please do not do any of the following, as none of it is covered above:

• denial of service, volumetric testing, or anything that degrades availability;
• automated scanning that generates significant traffic — tell us first and we will arrange a window;
• social engineering of us, our providers, or our users, and any form of physical access attempt;
• accessing, modifying or exfiltrating data belonging to anyone other than yourself;
• bulk abuse of the sign-in email endpoint, or spamming real addresses with codes;
• reports that consist solely of a missing best-practice header with no demonstrated impact, or of findings in a third party's own infrastructure — take those to Vercel, Stripe or Resend directly.

4. What the architecture rules out

The strongest security property we have is not a control we added; it is a category of risk the design removes. Because every tool edits files on your device and uploads nothing, there is no document store to breach. No bucket of customer artwork, no thumbnail cache, no temp directory of half-processed video. An attacker who fully compromised our hosting account would find application code and a list of email addresses, and not a single one of your files.

For the same reason there is no password database: sign-in is a one-time code sent by email, so there are no hashes to crack and no credential-stuffing surface. And because we set no cookies, the classic cross-site-request-forgery-against-a-session-cookie attack has nothing to forge.

5. Transport and headers

Everything is served over HTTPS, with HTTP redirected and HSTS set with a long max-age covering subdomains. This site additionally ships a strict Content-Security Policy that permits scripts and styles only from our own origin — the one inline script, which sets your theme before first paint, is allow-listed by SHA-256 hash rather than by opening the policy up. Framing is denied, MIME sniffing is off, the referrer policy is strict-origin-when-cross-origin, and camera, microphone, geolocation and USB are disabled by permissions policy.

6. Secrets

API keys and signing secrets live in server-side environment variables, are read only inside serverless functions, and are never included in a browser bundle. If a secret were ever exposed we would rotate it and say so. Local development configuration is kept out of version control, and example configuration files contain placeholders rather than real values.

7. Accounts and sessions

Sign-in emails a six-digit single-use code that expires in minutes. The token your browser then holds is signed by us and treated as a display hint only — it tells the interface what to draw, and it is never trusted for access. Entitlement is re-checked server-side against the payment provider on every request that matters, so editing the token in your own browser changes what you see and not what you can do.

8. Payments

Card details are handled entirely by Stripe on Stripe's own pages. We never see, hold or transmit a card number, so our systems are not in the cardholder data environment at all. During the free-access window the checkout path is refused server-side, which means a stale browser tab cannot start a subscription.

9. Dependencies

The apps are deliberately thin on runtime dependencies — the hub ships five — which is as much a supply-chain decision as a performance one. Every dependency is a party you are implicitly trusting, so there are few of them and they are well-known. We update them when advisories warrant it.

10. What we do not have yet

What we do have is a small attack surface, an honest description of it, and a commitment to tell you if something goes wrong rather than hoping you do not notice. If a breach ever affects your data we will email affected account holders and post a note here.

11. Contact

Security reports: our security inbox, subject line "Security". Machine-readable contact details are at /.well-known/security.txt.