Home/Security

Security and responsible disclosure.

How PomoZentra is protected, what we do not claim, and how to report a vulnerability privately. Last updated August 1, 2026.

Report a vulnerability

Email [email protected] with "Security" in the subject. We acknowledge within two business days. Please do not open a public issue or post details before we have replied.

What we claim, and what we do not

PomoZentra is an early-access product built by an independent studio. We hold no security certifications: no SOC 2, no ISO 27001, no third-party audit. If your organisation requires vendor certification before adopting a tool, PomoZentra does not currently meet that bar, and we would rather you knew that here than after a procurement review.

We also will not tell you that your data is completely secure, because nobody operating a real service can promise that honestly. What follows is what is actually in place.

How the product is protected

  • Transport. All traffic runs over HTTPS. HTTP requests are upgraded.
  • Isolation between accounts. Your workspace lives in a managed Postgres database with row-level security, so an authenticated session can only read and write the row belonging to that account. This is enforced by the database itself rather than by application code alone.
  • Authentication. Sign-in is Google OAuth only. We never see, store or transmit a password, and there is no password reset flow to attack. Account security therefore inherits whatever protection your Google account has, including its two-factor setting.
  • Sessions. Handled by our authentication provider. Signing out clears the local copy of your workspace from that browser, which matters on shared machines.
  • Content security policy. The site sets a restrictive CSP limiting where scripts, styles, fonts and network connections may come from.
  • Local-first data. Your workspace is held in your own browser first and synced to the server. In guest mode nothing reaches our servers at all.

Who can access production data

Access to the production database is limited to the people at Nozentra who operate the service, and is used for maintenance and for investigating problems that have been reported to us. We do not browse workspaces, and we do not read task titles or notes for any purpose beyond making the product work or answering a support request you have raised.

Infrastructure

The site and application are hosted on Cloudflare. The database, authentication and file storage are provided by Supabase. Error monitoring uses Sentry, product analytics uses PostHog, and transactional email uses Resend. The privacy policy explains what each one receives.

Incident response

If we become aware of a breach affecting user data, we will investigate, contain it, and tell affected users directly with a description of what happened, what was exposed and what changed as a result. We would rather send an uncomfortable email than a vague one. There has been no such incident to report.

Reporting a vulnerability

Send it to [email protected] with "Security" in the subject line. Useful reports include what you found, the steps to reproduce it, and what an attacker could achieve. A short proof of concept helps more than a scanner export.

Please do not include real personal data, credentials or another person's information in your report. If demonstrating an issue requires access to data that is not yours, describe the path rather than exercising it.

What is in scope

  • pomozentra.com and app.pomozentra.com
  • Authentication, session handling and account isolation
  • The public API endpoints under /api/

What is out of scope

  • Findings that only affect an outdated browser you control
  • Automated scanner output with no demonstrated impact
  • Missing hardening headers with no exploitable consequence
  • Denial of service, load testing, or anything that degrades the service for others
  • Social engineering of Nozentra people or our vendors
  • Physical attacks, or attacks against our third-party providers rather than against us
  • The pre-launch access gate. It is a soft gate to keep pages off the public site, not a security boundary, and we know it

Good-faith research

If you follow the boundaries above, report privately, give us a reasonable chance to fix the issue before disclosing it, and avoid accessing or destroying data that is not yours, we will treat your research as authorised and will not pursue action against you for it. We will credit you if you would like that, and tell you when the issue is fixed.

There is no paid bug bounty programme. We would rather say so plainly than let anyone spend time expecting one.

Response expectations

StageWhat to expect
AcknowledgementWithin two business days
Initial assessmentUsually within a week, with our view of severity
FixDepends entirely on severity and complexity. We will tell you what we are doing rather than go quiet
DisclosureCoordinated with you once a fix is live

Questions

Anything else security related: [email protected]. See also the privacy policy, the data deletion page and the terms.