Security

Effective 8 October 2026.

How we protect Sheet Reserve

Encrypted connections. Every page is served over HTTPS (TLS), and HTTP Strict Transport Security (HSTS) tells browsers to use HTTPS for every later visit.
Passwords. Stored only as Argon2id hashes. We never store your password itself.
Sessions. Session tokens are random, and we store only a hash of each one, so the database alone can't be used to take over a session. The session cookie is HttpOnly, Secure and SameSite=Lax.
Forms. Protected against cross-site request forgery (CSRF).
Content Security Policy. A strict policy limits what browsers will load and run on our pages, which helps block injected scripts.
Sign-in protection. Rate limiting and progressive delays slow down password guessing.
Email verification. Accounts must confirm their email address.
License keys. Encrypted at rest.
Secrets. API keys, encryption keys and other secrets are kept out of the source code.
Network protection. Cloudflare sits in front of the site to absorb denial-of-service attacks and filter out bots.
Payments. Handled by Gumroad. Card details never reach our servers.
Account notices. We email you when your password changes, and when someone tries to register with your email address.

The Privacy Policy explains what data we hold and for how long.

Reporting a vulnerability

If you think you've found a security problem, email [email protected] with the subject line "Security". Please include:

a description of the problem and what an attacker could do with it;
the URL, page or feature affected;
step-by-step instructions to reproduce it, with any proof-of-concept code or screenshots;
the browser and tools you used; and
how we can contact you.

Please don't include other people's personal data in your report beyond what's needed to show the problem.

Scope

In scope:

the website at https://sheetreserve.com, including sign-up, sign-in, sessions, password reset, email verification, membership activation and downloads.

Out of scope:

services run by other companies, including Gumroad, Google, Cloudflare and Namecheap (report problems in their systems to them);
denial-of-service and load testing;
social engineering, phishing and physical attacks; and
output from automated scanners that doesn't show a real, exploitable problem.

Rules for good-faith research

Test only with your own accounts, or with accounts whose owners have given you permission.
Don't access, change or delete data that isn't yours beyond the minimum needed to show the problem. If you come across someone else's data, stop and tell us.
Don't run denial-of-service attacks, or send so many requests that the site slows down for others.
Don't use social engineering, phishing or physical attacks.
Give us reasonable time to fix the problem before you disclose it publicly.

If you're unsure whether something is allowed, ask us first.

Safe harbor

If you follow these rules in good faith, we'll treat your research as authorized, we won't take legal action against you or report you to the authorities because of it, and we'll work with you to understand and fix the problem. This covers only Sheet Reserve. We can't authorize testing of other companies' systems, and we can't speak for those companies or for the authorities.

What to expect

We aim to acknowledge reports within a few days.
We'll look into what you've found, may ask you for more detail, and will keep you informed as we work on a fix.
We don't run a bug bounty program, so we can't pay for reports.

Keeping your account safe

Use a strong password that you don't use anywhere else.
If you get a security notice you didn't expect, such as an email saying your password was changed, reset your password and email us.

If a breach happens

If a security breach affects your personal data, we'll notify you and the relevant authorities as the law requires.

We may update this page. Material changes are announced as described in the Terms of Service.