English | Italiano

PlotMark's application source lives in a separate private repository. This page describes the security posture and how to report an issue for the public project.

The app is at version 1.x. Security fixes are applied to the current release.

To report a security vulnerability, use GitHub Security Advisories.

Please include:

• Description of the vulnerability
• Steps to reproduce
• Expected vs actual behavior
• Impact assessment (what an attacker could achieve)

Response timeline:

• Acknowledgment: within 72 hours
• Fix for critical issues: within 30 days
• Coordinated public disclosure after the fix is released

Personal watch data is protected by Firestore Security Rules, not by API keys. The following measures are implemented in the application:

• Authentication required: every data path requires a signed-in user.
• Per-user ownership: a user can only read and write their own documents.
• Read-only, spoiler-safe sharing: buddies read a projection that omits private notes; the rules enforce the allowed fields and explicitly reject a notes field.
• Write shape and size validation: writes must match an exact set of fields with bounded sizes (user profile, public profile, shared activity, custom lists, and the shared titles cache).
• Admin actions gated by an allowlist: privileged writes are limited to explicit user ids in the rules.
• Client-side input validation: Firestore reads and TMDB responses are revalidated with Zod schemas before use, so malformed documents are discarded rather than trusted.
• HTTP security headers and CSP: Firebase Hosting sends X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy, and a Content Security Policy that restricts sources and sets object-src 'none' and frame-ancestors 'none'.
• No secrets in source control: environment files are gitignored. The Firebase and TMDB keys are intentionally client-side and gated by Security Rules and TMDB's own limits, not treated as secrets.
• Rules tested in CI: the Security Rules run against the Firestore emulator in continuous integration.

The design rationale, including why the keys are public and why the rules are the authorization boundary, is summarized in ARCHITECTURE.md.

The following are not considered vulnerabilities for this project:

• Self-XSS (attacks requiring the victim to paste code in their own console)
• Social engineering attacks
• Physical attacks against infrastructure
• Vulnerabilities in third-party dependencies already publicly disclosed (report these to the upstream maintainer)
• Denial of service through excessive legitimate use
• Extraction of the client-side Firebase or TMDB keys, which are public by design and gated by Security Rules and TMDB's own limits

Security researchers who responsibly disclose vulnerabilities will be listed here.

Back to README