Security & Responsible Disclosure

1. Our promise to researchers

If you find a security problem in TOVELU and tell us about it privately and in good faith, we will thank you, fix it, and we will not pursue legal action against you. We consider good-faith research conducted within this policy to be authorised access under the computer-misuse laws that apply to us, and we will say so if a third party suggests otherwise. We will not ask your hosting provider or employer to act against you.

This safe harbour depends on you following Section 3. It does not extend to accessing, downloading, altering or retaining other people's personal data — and TOVELU holds people's medical information, which is exactly the data you must not touch.

2. Scope

• tovelu.store and its subdomains
• app.tovelu.store — the TOVELU web application
• Our public API endpoints and webhook handlers

Third-party services we use (our payment processor, database, email and affiliate providers) are out of scope here — please report those to the provider directly. We will help you reach them if that is easier.

3. Rules of engagement

• Test only against accounts you own or have explicit permission to use. Create your own test account.
• Never access, modify, copy, download or retain another person's data. If you accidentally see any — particularly any health information — stop immediately, do not save it, tell us, and delete anything you obtained.
• Use the minimum interaction needed to prove the issue. One proof-of-concept, not a campaign.
• No denial-of-service, load testing, brute forcing, spamming or resource exhaustion.
• No social engineering, phishing or physical intrusion against us, our users, our contractors or our providers.
• No automated scanning that degrades the service for real users.
• Do not publish or share the issue until we have fixed it and agreed timing with you.
• Follow the law where you are.

4. Out of scope

We will read every report, but the following are unlikely to be treated as vulnerabilities: missing security headers with no demonstrated impact, reports produced solely by an automated scanner with no proof of exploitability, clickjacking on pages with no sensitive action, missing SPF/DMARC hardening on non-sending domains, self-XSS, rate-limit findings that require unrealistic volumes, outdated library versions without a working exploit path, and vulnerabilities requiring a fully compromised device or physical access.

5. How to report

Email ask@tovelu.store with the subject “Security”. Please include: what the issue is, where, step-by-step reproduction, what an attacker could do with it, and any proof-of-concept. Tell us if you would like to be credited and under what name. Report in English if you can.

If the issue is being actively exploited, say so in the first line.

6. What happens next

• Acknowledgement within 48 hours.
• An assessment within 5 business days, telling you whether we have reproduced it and how serious we think it is.
• We aim to fix critical issues within 7 days and other issues within 90 days, and we will keep you updated.
• We will tell you when it is fixed, and agree with you when and how it can be disclosed publicly.

7. Recognition and rewards

TOVELU is a small, self-funded product and does not currently run a paid bug-bounty program. We offer public credit on this page with your permission, a genuine thank-you, and free access to TOVELU where that is useful to you. We would rather be honest that we cannot pay competitively than imply a bounty that does not exist.

8. How we protect the service

• TLS everywhere, HSTS, and hardened response headers.
• Database row-level security, so a user's records are readable only by their own authenticated session, enforced by the database itself.
• Passwords hashed and salted by our authentication provider; never visible to us.
• No payment card data on our systems — our Merchant of Record handles it entirely.
• Cryptographic signature verification on payment webhooks; unsigned or forged calls are rejected.
• Rate limiting on sensitive endpoints, and least-privilege access to administrative credentials.
• Food photographs are processed in memory and never stored.

9. If a breach happens

If a personal-data breach occurs that is likely to result in a risk to people, we will notify the competent supervisory authority within 72 hours where required, notify affected users without undue delay in plain language, and say what happened, what data was involved, what we have done and what you should do. We will not minimise it and we will not wait for it to become public first. See also the Privacy Policy.