31 lines
1 KiB
Markdown
31 lines
1 KiB
Markdown
# Security Policy
|
|
|
|
## Supported Versions
|
|
|
|
This project currently supports the latest active branch in this repository.
|
|
|
|
## Reporting a Vulnerability
|
|
|
|
If you discover a security issue, please do not open a public issue with exploit details.
|
|
|
|
Preferred process:
|
|
|
|
1. Share a private report with:
|
|
- A clear description of the issue
|
|
- Reproduction steps
|
|
- Impact assessment
|
|
- Suggested fix (if available)
|
|
2. Allow time for triage and remediation before public disclosure.
|
|
|
|
## Scope Notes
|
|
|
|
- Supabase anon keys are client-side by design and are not secret credentials.
|
|
- Real protection depends on strict RLS policies, RPC authorization, and server-side validation.
|
|
- Local config files with runtime values should stay out of version control.
|
|
|
|
## Recommended Hardening
|
|
|
|
- Keep Supabase keys in local/CI `dart-define` configuration only.
|
|
- Rotate keys when moving between environments or if misuse is suspected.
|
|
- Audit RLS policies after every schema/function change.
|
|
- Sanitize user-facing error messages (avoid leaking backend internals).
|