How to report

Email hello@mysuvo.com with enough detail to reproduce it: the URL, what you did, what happened, and what you expected. A proof of concept helps. So does telling me how bad you think it is and why.

Machine-readable version at /.well-known/security.txt (RFC 9116).

What I promise

• I'll acknowledge your report within a few days. I'm one person and a student, so it may not be same-day.
• I'll tell you honestly whether I think it's a real issue, and if I disagree, I'll say why rather than going quiet.
• I'll fix anything real, and tell you when it's done.
• I won't take legal action against you for a good-faith report that follows this page.
• Credit on this page if you want it, or your silence if you'd rather.

What I ask

• Give me a reasonable window to fix it before publishing. 90 days is the usual courtesy; if it's trivial, I'll be faster.
• Don't access, modify, or delete data that isn't yours. If you find a way into the analytics database, stop there and tell me — I don't need a demonstration of how much of other people's data you could have read.
• Don't run automated scanners at volume. This runs on free tiers; the noise costs me money and tells you nothing a careful look wouldn't.
• No denial of service, no social engineering, no physical anything.

In scope

www.mysuvo.com and the endpoints under it (/api/track, /api/github, /api/health, /admin).

Out of scope

These aren't mine to fix — please report them upstream:

• Anything in my GitHub repositoriesas a platform issue — that's GitHub. (Bugs in my code in those repos are welcome, just open an issue there.)
• Vercel, Neon, and any *.vercel.app deployment infrastructure.
• Live demos linked from project pages that run on someone else's host.

Already known — please don't spend your time here

Every one of these is a deliberate, documented tradeoff rather than an oversight. I'd rather list them honestly than have you spend an evening writing up something I decided on purpose.

script-src allows 'unsafe-inline'

Known and deliberate. Next.js emits inline bootstrap scripts, and the theme script must run before hydration to avoid a colour flash. Locking it down needs a per-request nonce, which forces every page out of static generation. The policy still blocks script from any third-party origin, which is the realistic vector — the site renders no user-supplied HTML anywhere. Reports of this alone will get a polite version of this paragraph.

/api/track accepts unauthenticated POSTs

By design — a tracker that required a credential would have to ship one to every browser. It's same-origin checked, bot-filtered, rate-limited, size-capped, and validates against a closed event vocabulary. The worst case is junk rows in my own chart. If you can get it to do something else, I want to hear about it.

Rate limits are per-instance

Serverless instances don't share memory, so the true limit is (limit x live instances). A distributed limiter needs Redis to defend a route whose worst case is a bad bar chart. Known tradeoff, documented in the code.

Missing SPF/DMARC on a domain that sends no mail

Worth a mention if you're being thorough, but this site sends no email at all.

What this site actually does to protect you

A Content-Security-Policy that blocks script from every origin but this one, plus framing, form hijacking, and <base> injection. HSTS with a two-year max-age. No third-party script, tag manager, or ad network anywhere — so nothing on this page can watch you, because nothing on this page is theirs. Your IP is never stored; the analytics keep a daily-rotating salted hash instead. Details on the privacy page.

Changes

Last updated: 2026-07-16.