1. How to report
Lodge your report via the security contact form with as much detail as you can provide: the vulnerability, affected URL or component, reproduction steps, suspected impact, and any proof-of-concept payload (please mark this clearly).
We accept reports in English. The form posts directly to our security triage queue and creates a tracking reference you can quote in any follow-up.
If your report involves a sensitive secret you have already discovered (an exposed API key, a leaked credential, an accidentally public storage object), please do not include the live secret value in the form. Tell us what the secret is and where, and we will reach back out via a more secure channel.
2. What we promise
- We will acknowledge your report within two business days (Australian Central Time).
- We will give you an initial triage with our severity assessment within seven calendar days.
- For Critical and High severity findings we will commit to a remediation timeline in writing and keep you updated as we work through it.
- We will let you know when the fix has been deployed.
- With your permission, we will name you in our acknowledgements (see §6) after the fix is live.
3. Safe harbour
When you research and report in good faith and in accordance with this policy, UniRubric will:
- Not initiate or support legal action against you for the research or for the report itself.
- Treat your report as an authorised activity under the relevant Australian computer-misuse provisions (including the Criminal Code Act 1995 (Cth) Pt 10.7 and the Crimes Act 1914 (Cth)) and comparable laws in your jurisdiction.
- Work with you to understand and resolve the issue quickly.
This safe harbour does not extend to actions that are inconsistent with this policy (see §5).
4. In scope
unirubric.comand all its sub-paths.app.unirubric.com— the application surface.admin.unirubric.com— internal command centre (out of scope for unauthenticated probing; in scope only for reports that do not require credentials).api.unirubric.com— the public API (when GA).developers.unirubric.com— developer portal.- UniRubric's LTI 1.3 tool endpoints, regardless of host.
4.1 Vulnerability classes we care about most
- Authentication, authorisation, and session-handling flaws.
- Cross-tenant data exposure or RLS bypass.
- Prompt-injection vectors that bypass our rubric-anchored substring validation or our tone-pass guardrails.
- LTI 1.3 handshake, deep-linking, NRPS, or AGS attacks.
- SSRF, XXE, SQLi, NoSQLi, RCE, deserialisation, business-logic bypasses.
- Stored or reflected XSS in submission-handling surfaces.
- CSRF on state-changing endpoints.
- Exposed secrets or PII in error responses or build logs.
5. Out of scope and not eligible for safe harbour
- Findings that require physical access, social engineering of UniRubric staff, or compromise of an end user's device.
- Denial-of-service testing, distributed denial-of-service testing, or any test that degrades availability for legitimate users.
- Automated scanning that generates significant load. Please rate-limit your tooling and tell us in advance if a scan is necessary.
- Vulnerabilities exclusively in third-party services we depend on (Anthropic, Supabase, Vercel, Cloudflare, Stripe, etc.). Please report those directly to the vendor and copy us so we can track impact.
- Findings derived from publicly disclosed CVEs in dependencies for which a fix is not yet available upstream.
- Self-XSS, missing security-header recommendations on static assets, clickjacking on pages without state-changing actions, and other low-impact issues unless chained into a meaningful attack.
- Accessing, modifying, exfiltrating, or destroying data that is not your own beyond the minimum necessary to demonstrate the finding. If you must demonstrate access to a record, access only one record, and not one that contains identifiable student work.
Activities outside this policy may be referred to law enforcement. If you are uncertain whether a planned activity is authorised, ask first via the security contact form.
6. Acknowledgements (Hall of Thanks)
With each researcher's consent we publish the name and an optional handle of every person who has reported a valid finding. UniRubric does not currently operate a paid bug-bounty program. Researchers who want a private write-up of their finding for their portfolio can request one once the fix is live.
No public acknowledgements yet. You could be the first.
7. Coordinated disclosure
We commit to coordinated disclosure with you. We will not disclose your finding to a third party before we have agreed a disclosure date with you, and we will not name you publicly without your prior consent.
If a finding affects multiple parties or a shared dependency, we will work with you to align a coordinated disclosure with the other affected parties.
8. What this policy is not
This policy is not a contract and does not constitute a paid engagement. It is not an authorisation to test third-party systems. It is not a substitute for any consent or authorisation you may need from your employer, your institution, or other parties.
9. Contact and updates
For all matters relating to this policy, use the security contact form.
This policy is maintained in our public-facing legal kit. The canonical machine-readable pointer to it is at unirubric.com/.well-known/security.txt.