Skip to main content

Security & Vulnerability Disclosure

Growing Standard LLC · Last updated April 2026

Growing Standard LLC operates Potato Class (potatoclass.com) and the Growing Standard marketing and district portal (growingstandard.com). We handle K-12 student data under FERPA, COPPA, and state student-data privacy laws. If you are a security researcher and you believe you have found a vulnerability in either site or in our backend services, this page tells you how to report it and what to expect from us.

Report a vulnerability: security@growingstandard.com
Machine-readable contact at /.well-known/security.txt (RFC 9116).

Scope

In scope.

  • potatoclass.com and all subdomains
  • growingstandard.com and all subdomains
  • Our Cloudflare Worker API endpoints (TTS proxy, quote-form, admin-access-notify, Clever/ClassLink OAuth handlers)
  • Our Firebase authorization rules and deployed Cloud Functions
  • The Potato Class web client and the Growing Standard web app

Out of scope.

  • Third-party vendor infrastructure we rely on (Clever, ClassLink, Vercel, Cloudflare, Firebase, Google Cloud, Resend). Report those directly to the vendor.
  • Denial-of-service, volumetric, or resource-exhaustion attacks. Please do not run them against our production services.
  • Social engineering of Growing Standard staff, contractors, customers, students, or their families.
  • Physical attacks, or attacks that require physical access to a user’s device.
  • Findings from automated tools that are not reproducible or that do not identify a concrete security impact (e.g., a missing header that we have intentionally omitted with a compensating control).
  • The iPad app is not in scope for this disclosure policy at this time. If you find an issue there, please still email us; we will triage it but cannot commit to the response SLA below.

Safe harbor

We will not pursue legal action against good-faith security researchers who follow this policy. Specifically, as long as your research stays within the rules below, we consider your activity authorized under the Computer Fraud and Abuse Act (18 U.S.C. §1030), the Digital Millennium Copyright Act (17 U.S.C. §1201(j) for security research), and applicable state computer-crime laws. We will not ask law enforcement to investigate or charge you, and we will not pursue civil action, provided you act in good faith under this policy.

If a third party brings legal action against you for activity conducted in good faith under this policy, we will take reasonable steps to make it known that your activity was authorized.

Rules of engagement

  • Do not access real student data. Our users are children. Use test accounts you register yourself. If you inadvertently access real student data, stop immediately, do not save or share it, and tell us what happened.
  • Do not interact with other users’ accounts or data except with their explicit permission or via accounts you created yourself.
  • Do not degrade service. No DoS, no volumetric testing, no stress tests. If you need to test rate limits, stop as soon as you confirm the control exists.
  • Minimize your proof-of-concept. Demonstrate the vulnerability with the smallest payload and smallest scope sufficient to show impact.
  • Do not publicly disclose before we fix it. Give us 90 days from initial report before public disclosure, or until we confirm a fix is live (whichever comes first). We will coordinate timelines for complex issues.
  • Do not demand payment. We do not currently run a paid bug-bounty program. We will acknowledge your contribution (if you want public credit) and escalate internal decisions about future compensation programs.

What to include in your report

  • A description of the vulnerability and why it matters.
  • Steps to reproduce (URL, request, payload, expected vs. observed).
  • Any proof-of-concept artifacts (screenshots, video, scripts).
  • Affected components (web, backend, Worker endpoint, auth flow, etc.).
  • Your assessed severity and impact (what an attacker could do, what data is at risk).
  • How you want to be credited, if you want public credit, or whether you prefer to remain anonymous.

Response SLA

  • Acknowledgment within 72 business hours of your report.
  • Initial triage within 7 days— we will tell you our assessed severity and expected fix timeline.
  • Fix timeline depends on severity. Critical and high-severity issues are prioritized over routine engineering work. We target 7 days for critical, 30 days for high, 90 days for medium, next maintenance window for low.
  • Post-fix confirmation. We will tell you when the fix ships and invite you to re-test.

Recognition

We maintain an informal list of researchers who have reported valid issues to us and wanted public credit. If you would like to be listed, tell us in your report. We do not currently pay monetary bounties, but we will acknowledge your work publicly (with your permission) once the issue is fixed.

Coordinated incident disclosure to districts

If a confirmed incident affects student data of a district we serve, we will notify the district’s designated privacy contact within 24 hours of discovery and deliver a full written incident report within 72 hours, per our standard data privacy agreement and Va. Code §18.2-186.6. This applies regardless of whether the finding originated from this disclosure program or from our own monitoring.

Related resources

Growing Standard LLC · Virginia, USA · Contact: security@growingstandard.com