Open Specter is built for legal teams handling sensitive matters. We take security reports seriously and appreciate the community's help in keeping the project safe.
Please do not open a public GitHub issue for security vulnerabilities.
Instead, report privately via one of:
- Email:
security@quantera.ai - GitHub Security Advisories: use the "Report a vulnerability" button on the repository's Security tab.
When reporting, please include:
- A description of the vulnerability and its potential impact.
- Steps to reproduce (proof-of-concept code, screenshots, or curl/HTTP transcripts are very helpful).
- The affected version (commit SHA or release tag).
- Your environment (Node version, Supabase region, deployment target).
- Any suggested mitigation, if you have one.
| Stage | Target turnaround |
|---|---|
| Acknowledgement of report | Within 2 business days |
| Initial triage / severity assessment | Within 5 business days |
| Fix released for high/critical issues | Within 30 days of triage |
| Public disclosure (coordinated) | After a fix ships, or 90 days, whichever first |
We follow coordinated disclosure and will credit reporters in the release notes unless anonymity is requested.
In scope:
- The Open Specter Express backend (
backend/) - The Open Specter Next.js frontend (
frontend/) - The Supabase migrations and RLS policies shipped in this repository
- The bundled edge functions under
supabase/functions/
Out of scope:
- Third-party services we integrate with (Supabase, Cloudflare R2, Gemini, Anthropic, OpenRouter, Resend, LegalDataHunter). Report those to the respective provider.
- Self-hosted deployments where the operator has modified the security configuration (RLS disabled, service role key exposed client-side, etc.).
- Issues requiring physical access to a user's device or that depend on social-engineering an authenticated user.
- Best-practice recommendations without a demonstrated impact.
If you operate Open Specter for an organization, please review the following before going to production:
- Never expose
SUPABASE_SECRET_KEYto the browser. It is a service-role key that bypasses Row Level Security. It belongs only in the backend.envand in trusted server processes. - Apply Row Level Security: run both
backend/migrations/000_one_shot_schema.sql(or the equivalent rebuilt schema) and confirm that RLS isENABLEDon every content table in the Supabase Table Editor. - Rotate keys on day one. The example env files are templates — every production deployment should generate fresh Supabase service-role, Gemini, Anthropic, OpenRouter, Resend, R2 and LegalDataHunter keys.
- Use object storage in production. The local-disk storage fallback is for development only — files do not persist across pod restarts and have no encryption at rest.
- Restrict CORS to your real frontend origin (
FRONTEND_URLenv var) rather than*once you have stable hostnames. - Pin dependency updates. Watch GitHub Dependabot alerts; the legal-tech data flowing through Open Specter increases the blast radius of any upstream CVE.
- Audit logs: forward Supabase Auth logs and the Express access logs to
your SIEM. Anonymous (guest) sessions are subject to a 7-day cleanup; if
you need shorter retention, edit
supabase/functions/cleanup-anonymous-users/.
We provide security fixes for the most recent minor release and the previous one. Older versions are best-effort.
| Version | Supported |
|---|---|
latest main |
✅ |
| previous minor release | ✅ |
| anything older | ❌ |