My wife needed a cycle tracker. Everything out there was either Flo (which got sued twice for sharing health data) or an abandoned GitHub project. So I built Ovumcy. Single Go binary, SQLite, Docker-ready. No analytics, no third-party APIs, no cloud. Your data stays on your server. Features: period tracking, symptom logging, predictions (ovulation, fertile window), statistics, CSV/JSON export, dark mode, Russian and English. Just pushed v0.2.5. Looking for feedback from real users.

you are viewing a single comment's thread
view the rest of the comments
[–] 49 points 7 months ago (6 children)

I recommend you set the Content-Security-Policy http header so that inline javascript (commonly used for XSS attacks) cannot be executed.

https://web.dev/articles/strict-csp

CSP being off is not exactly a security hole but it makes security holes much more likely. By using a strict CSP configuration you close off the possibility of a whole class of holes.

Also think about setting the Access-Control-Allow-Origin header and enable CORS on your REST endpoints.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Access-Control-Allow-Origin

Again, kind of a pain in the ass but gets rid of a bunch of potential problems before they start.

  • source
  • hideshow 6 child comments
  • [–] [S] 13 points 7 months ago (5 children)

    Thanks for the suggestions, those are good points.

    CSP is something I plan to tighten over time, but enabling a strict policy right now would require refactoring some inline JS patterns used in the templates. It’s definitely on the roadmap as part of security hardening.

    Regarding CORS, the application currently runs as a same-origin server-rendered app rather than a cross-origin API, so CORS headers aren’t enabled by default. If external clients or integrations are added in the future, I’d likely introduce a restricted allowlist for specific API routes.

  • source
  • parent
  • hideshow 5 child comments
  • [+] -10 points 7 months ago (4 children)

    Your releasing a health data app without doing security hardening?

    So much for you saying you take security seriously

  • source
  • parent
  • hideshow 4 child comments
  • [–] [S] 10 points 7 months ago (1 child)

    No, we didn’t ship it without security hardening.

    We already hardened the main sensitive parts:

    sealed auth/recovery/reset/flash cookies no auth or recovery secrets in URLs or JSON POST + CSRF logout basic browser security headers CodeQL, gosec, Trivy, and SBOM in CI What’s still missing is a strict CSP. That’s not a one-line switch here because the current frontend still needs some refactoring first.

  • source
  • parent
  • hideshow 1 child comment