Security Policy

Responsible-disclosure policy, security contact, and recognition for researchers who help us improve site security. This is the human-readable companion to /.well-known/security.txt.

Reporting a vulnerability

If you believe you've found a security issue affecting togopeptide.com, our APIs, our serverless functions or any data we hold, please tell us. We take every report seriously.

  • Primary contact: security@togopeptide.com
  • Languages: English, Dutch, German.
  • Encrypted contact (optional): request the current PGP key via security@togopeptide.com when needed.
  • Acknowledgement target: within 3 business days.
  • Resolution target: P0 within 24 h, P1 within 7 days, P2 within 30 days, P3 best-effort.

Scope

In scope:

  • togopeptide.com and all subdomains.
  • Netlify Functions under /api/* and /api/*.
  • Authentication, account, checkout, GDPR-rights and admin flows.
  • Storage, rendering or transport of customer data.

Out of scope:

  • Reports against third-party processors directly — please report those to the processor (Mollie, Supabase, Resend, Netlify, GitHub) per their own policies.
  • Volumetric DoS / DDoS testing without prior written agreement.
  • Social-engineering of staff, family or customers.
  • Reports purely about missing security headers without a demonstrated impact (we welcome low-severity hardening notes, but they are P3).
  • Automated scanner output without proof-of-concept.

What you can expect from us

  1. Acknowledgement within 3 business days.
  2. Triage and severity assignment within 5 business days.
  3. Status updates at least every 7 days while the issue is open.
  4. Public credit (with your permission) on the recognition list below once the issue is fixed.
  5. No legal action against good-faith research that follows this policy.

What we ask of you

  • Give us reasonable time to fix an issue before public disclosure (90 days as a default).
  • Do not access, modify or download data that does not belong to you.
  • Do not run automated scanners that generate excessive load.
  • Do not pivot, persist or attempt to escalate beyond what's needed to demonstrate the issue.
  • Use a test account (not someone else's) for any flow that requires sign-in.
  • Report promptly — ideally before sharing details with anyone else.

Bug bounty disclosure

We do not currently operate a paid bug-bounty programme. We're a small operation and want to be honest about that — we'd rather under-promise than dangle a payout we can't yet sustain. We do, however, deeply value responsible disclosure and offer:

  • Public credit on the recognition list (with your permission).
  • A genuine thank-you, often with a small voucher or merch when we can.
  • A direct line to the team for follow-up research.
  • An honest commitment that, if we ever do launch a paid programme, prior contributors get retroactive credit and an invite to the private tier.

Promotion of this section to a real cash-payout programme is on the security roadmap once volume justifies it.

Recognition

We thank the following researchers for responsible disclosure (most recent first). If your name should be here, email us with the report reference and how you'd like to be credited.

  • The list is currently empty — you could be the first.

Public list: /security-acknowledgments.html (created automatically once we have entries).

Security posture

  • TLS 1.2+ enforced; HSTS on the apex domain.
  • Strict Content-Security-Policy with allow-listed CDNs only.
  • Service-role keys server-side only; principle of least privilege across processors.
  • Webhook signature verification on Mollie events.
  • Audit-style logging for admin writes; rate-limit on public endpoints.
  • We deliberately do not claim ISO 27001, SOC 2 or any other certification we have not actually undergone.

Last reviewed

2026-05-06. We re-review this policy at least once per year, or whenever the architecture changes meaningfully.