security policy

We take security seriously. If you've found a vulnerability in any Wymzy product, we appreciate your report.

How to report

Email security@wymzy.ai with:

• A clear description of the issue
• Steps to reproduce (or a proof-of-concept)
• The version / URL / endpoint affected
• Your name + a way to credit you (optional)

If you want to encrypt the report, request our PGP key at the same address and we'll respond with one.

What's in scope

• wymzy.ai (the marketing site)
• app.wymzy.ai (the unified Wymzy suite)
• persimmon.tools (Persimmon, our free-tools site)
• Any public API endpoint under app.wymzy.ai/api/*
• Customer-facing flows linked from any of the above (public booking pages, pay pages, customer portals, etc.)

What's out of scope

These are NOT in scope. Please don't test them — and reports against them will be closed without action:

• Third-party services we use (Stripe, Resend, Neon, Cloudflare, Vercel, Anthropic, R2). Report those to the vendor directly.
• Anything requiring physical access, social engineering against our staff, or attacks on Heath's personal accounts.
• Automated scanner output without a manually verified exploit (we get a lot of these; please confirm the issue is real before reporting).
• Best-practice complaints with no demonstrated impact (“you don't have a Content-Security-Policy header”, “TLS 1.0 enabled on a non-existent host”, etc.).
• Email spoofing tests that bypass our DMARC posture by using a different domain. Yes, anyone can send mail “from” support-wymzy@gmail.com— that's not a Wymzy bug.
• Self-XSS, clickjacking on non-sensitive pages, missing-rate-limit on endpoints that aren't actually exploitable.
• Findings against our open-source dependencies whose CVE is already disclosed upstream. Report to upstream.

Severity + response targets

We're a solo-founder shop. We answer real reports fast, but we don't have a 24/7 on-call rotation. Response targets:

• Critical (cross-tenant data leak, account takeover, payment-flow exploit, RCE): acknowledged within 24 hours; mitigation in flight within 72 hours.
• High (sensitive data exposure with auth bypass, persistent XSS in an authed surface): acknowledged within 3 business days; fix in flight within 2 weeks.
• Medium / Low: acknowledged within 5 business days; fixed in the next reasonable release cycle.

What we ask

While testing, please:

• Don't break production for real users.Test against your own account. No DoS, no mass enumeration, no leaking other customers' data even to demonstrate the issue.
• Don't access data that isn't yours.If you find a way in, stop at the smallest proof-of-concept that demonstrates the issue. Don't read, modify, or download other customers' records.
• Give us a reasonable window to fix.We follow coordinated disclosure — please don't publish or share details until we've had a chance to ship a fix. We'll keep you in the loop on timeline.

What you get from us

• A real response (not auto-acknowledgment).
• Credit in our security acknowledgments if you want it (or anonymous if you don't).
• Swag where appropriate — we're small but we appreciate the work.
• No formal bounty program yet.As we grow we'll add one; for now this is a “thank you + credit” channel, not a paid one. We won't pretend otherwise.

Safe harbor

If you make a good-faith effort to follow this policy:

• We will not pursue legal action against you under the Computer Fraud and Abuse Act, the Digital Millennium Copyright Act, or any other applicable law for activities consistent with this policy.
• We consider your activity authorized testing.
• We will work with you to understand and resolve the issue quickly.

This safe harbor does not apply to activity that violates the “What we ask” section above (e.g. accessing data that isn't yours beyond a minimal POC, running a denial-of-service, or selling / publicly disclosing the finding before we've had a chance to fix).

Acknowledgments

Researchers who have reported valid issues (most recent first):

(Empty — your name could go here.)