Responsible Disclosure Policy

The following systems, operated by us, are in scope for good-faith security research under this policy:

• allcadets.com — the production web application and all of its subdomains that we operate, including the marketing pages, authentication flows, Cadet and instructor interfaces, and administrative screens.
• The application’s backend APIs and the security rules governing access to our data store, insofar as they can be exercised from your own account.
• Client-side code we serve, including our JavaScript bundles and their configuration.

Vulnerability classes we are particularly interested in include authentication and session flaws; authorisation flaws and insecure direct object references, especially anything that lets one role or one school reach another’s records; privilege escalation between the Cadet, instructor, and admin roles; injection; server-side request forgery; cross-site scripting and cross-site request forgery; misconfigured database or storage security rules; and any exposure of Cadet personal information.

The following are not authorised under this policy. Testing them is not covered by the safe harbour in section 3.

Third-party services

We do not own these systems and cannot authorise testing against them. Stripe processes our payments and Google Firebase provides our hosting, authentication, and database infrastructure. Report vulnerabilities in those platforms to their own disclosure programs. A misconfiguration by us of a third-party service — for example, an over-permissive Firebase security rule on our project — is in scope, because that is our mistake, not theirs. The distinction is whether the flaw is in their product or in our use of it.

Prohibited testing techniques

• Social engineering of any kind against our staff, contractors, instructors, school personnel, or Cadets — including phishing, pretexting, vishing, and baiting. Cadets are children; do not contact them.
• Physical attacks against our staff, offices, or any school premises, including tailgating, device theft, and attempts to access school facilities or equipment.
• Denial-of-service and stress testing, including volumetric attacks, resource-exhaustion testing, and any activity that degrades the service. Schools depend on Cadets during the school day, and a Cadet locked out of their tasks is a real cost.
• Automated scanning at damaging volume, brute-force and credential-stuffing attacks, and spam or mass submission through any form or email channel.
• Testing against accounts, units, or schools that are not your own.

Findings we generally do not action

• Missing security headers, cookie flags, or TLS configuration preferences with no demonstrated exploit path.
• Output from an automated scanner submitted without validation or a working proof of concept.
• Self-XSS, and issues requiring the victim to paste code into their own console or to run a modified browser.
• Clickjacking on pages with no state-changing action, and CSRF on unauthenticated or non-sensitive endpoints.
• Descriptive rate-limiting, password-policy, or account-enumeration opinions with no demonstrated impact.
• Vulnerabilities affecting only outdated or end-of-life browsers.
• Publicly known issues within a reasonable remediation window after disclosure.

If you believe one of these has real impact in our specific context, send it anyway with the exploit path spelled out. We would rather triage a borderline report than miss a genuine one.

If you make a good-faith effort to comply with this policy during your research, we will:

• Consider your research authorised under the Computer Fraud and Abuse Act, and under state computer-crime and anti-hacking laws, and we will not initiate or support legal action against you in connection with it.
• Not pursue a claim against you for circumventing technical measures used to protect the service, to the extent such circumvention was necessary to your research and consistent with this policy.
• Waive any restriction in our Terms of Service that would otherwise prohibit the testing you conducted, for the limited purpose of that testing.
• If a third party brings legal action against you for research conducted in compliance with this policy, take reasonable steps to make it known that your activity was authorised by us.

This protection applies to your research activity only. It does not cover accessing or retaining another user’s personal data, disrupting the service, extorting us, or conduct outside the scope defined above. Safe harbour is extended by us and cannot bind third parties, law enforcement, or the operators of out-of-scope services; it does not authorise you to breach any other law or agreement. If you are unsure whether an action is covered, ask us at security@allcadets.com before you take it. We will answer, and asking first counts strongly in favour of good faith.

1. Use only your own test accounts. Do not register accounts using a real Cadet’s or instructor’s details, and do not test against a live school’s unit. Ask us and we will provision a test environment or test accounts.
2. Never access, alter, or exfiltrate another user’s data. See the box at the top of this page. This is the rule we will not make exceptions to.
3. Stop at proof. Once you have confirmed a vulnerability exists, stop. Do not pivot deeper, do not escalate further than needed to establish impact, and do not maintain access.
4. Do not modify or destroy anything. No changing records, no deleting data, no defacement, no leaving files, accounts, or backdoors behind. If your testing changed state, tell us in the report so we can restore it.
5. Keep testing volume low. Throttle automated tools. Do not degrade performance for the schools using the service during their school day.
6. Do not contact Cadets, instructors, or schools about your research. Route everything through us.
7. Keep it confidential. Do not disclose the vulnerability publicly or to anyone else until we have agreed a disclosure date, as set out in section 8.
8. Delete what you collected. Once the report is closed, securely delete any data obtained during testing and confirm to us that you have done so.
9. Comply with the law. Nothing in this policy authorises activity that is unlawful independent of our authorisation, and this policy is governed by the law of United States.

Reporting a vulnerability with a demand for payment as a condition of disclosure, or threatening publication to force a response, is extortion rather than research. It voids safe harbour and will be handled accordingly.

Send your report to security@allcadets.com. This is the only channel for vulnerability reports — please do not raise them through support@allcadets.com, through a school, or through social media, as that delays triage and widens exposure of the finding.

Write in English if you can. If you wish to encrypt your report, say so in an initial email without technical detail and we will arrange a secure channel. You may report anonymously; we can still triage and fix, though we will not be able to credit you or follow up on questions.

If you believe a vulnerability is being actively exploited, or that Cadet data is exposed right now, put URGENT in the subject line and say so in the first sentence. Where the exposure involves a risk to a child’s safety rather than only their data, copy safeguarding@allcadets.com. Questions about how we handle personal information generally go to privacy@allcadets.com.

• A short description of the vulnerability and its type.
• The affected URL, endpoint, parameter, or component, and the role required to reach it — unauthenticated, Cadet, instructor, or admin.
• Clear, numbered reproduction steps that someone unfamiliar with the finding can follow.
• A proof of concept: a request, a script, or a short screen recording. Redact any personal data that appears in it.
• Your assessment of impact — what an attacker could actually do, and to whom.
• Any prerequisites or preconditions, such as needing a valid account in the same unit.
• The date and approximate time of your testing, the source IP addresses you used, and any account identifiers you created. This lets us separate your activity from a genuine attack in our logs.
• Whether you encountered any personal data, and if so what and how much, and confirmation you have deleted it.
• How you would like to be credited, if at all.

Resolution targets run from validation, not from the date you reported. Where a fix depends on a third-party provider, we will say so and keep you updated on their timeline rather than ours. Where a vulnerability has exposed personal information, we handle notification to affected schools, users, and regulators separately under our incident-response and breach-notification obligations, independently of this policy.

We support coordinated disclosure and we do not ask researchers to stay silent indefinitely.

• The default embargo is 90 calendar days from the date we acknowledge your report. After that you are free to publish, whether or not we have fixed the issue.
• Where we fix and deploy sooner, you may publish once the fix is live and we have confirmed it — we will not hold you to the remaining time.
• We may ask for an extension where a fix is genuinely complex or where schools need lead time to act. We will explain why and propose a specific date. You are not obliged to agree.
• We ask that any publication omits Cadet personal data entirely, including screenshots that could identify a student, a unit, or a school. This is not negotiable regardless of the embargo.
• If you intend to request a CVE, tell us and we will coordinate rather than duplicate.
• If we discover an issue is being actively exploited, we may accelerate our own disclosure to protect users. We will tell you before we do.

We do not currently offer a monetary bounty for vulnerability reports. We would rather say so plainly than leave researchers guessing or imply a reward that does not exist. What we do offer is credit: with your permission, we will acknowledge you by name or handle in our security acknowledgements and in the release notes for the fix. Tell us in your report how you would like to be credited, or say that you would prefer to remain anonymous. We will never publish your name without your agreement.

We will also, on request, provide a written confirmation of your finding and its resolution that you can use professionally — for a portfolio, an employer, or a certification. If we later introduce a paid bounty, we will announce it on this page; it will not apply retroactively to reports already closed.

Postal correspondence about this policy may be sent to {{LEGAL_ENTITY}}, {{POSTAL_ADDRESS}}. We may update this policy; the version in force is the one published here on the date you begin testing.

Cadets is an independent product and is not affiliated with, endorsed by, or sponsored by the U.S. Department of Defense or any branch of the U.S. Armed Forces.