Please do not open a public issue for security vulnerabilities.

Report privately using GitHub's private vulnerability reporting: go to the Security tab of this repository and choose Report a vulnerability. If that is unavailable, contact the maintainers privately and wait for a reply before disclosing anything publicly.

Please include:

• A description of the issue and its impact.
• Steps to reproduce, or a proof of concept.
• The affected version, commit, or deployment configuration.

We aim to acknowledge reports within 5 working days and to provide a fix or mitigation plan within 30 days. We will credit you in the release notes unless you prefer otherwise.

This project is maintained on a best-effort basis. Only the latest commit on main receives security fixes.

In scope:

• The Django API in backend/.
• The React client in frontend/.
• The Docker and Compose configuration.

Out of scope:

• Vulnerabilities in the Groq API itself — report those to Groq.
• Findings that require a deployment to have ignored the checklist below (for example, running with DJANGO_DEBUG=1 on a public host).

Work through this before exposing an instance to the internet.

• DJANGO_SECRET_KEY is set to a unique, random 50+ character value. Never reuse the development fallback. Generate one with: python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"
• GROQ_API_KEY is set and scoped to this application.
• No .env file is committed. Confirm with git check-ignore -v .env.
• Secrets are injected through your platform's secret store, not baked into an image or a compose file.
• Keys are rotated if they were ever pasted into a shared channel, a build log, or a repository — including a private one.

• DJANGO_DEBUG=0. The application refuses to start in production without DJANGO_SECRET_KEY, DJANGO_ALLOWED_HOSTS, DJANGO_CORS_ALLOWED_ORIGINS and GROQ_API_KEY; do not work around those checks.
• DJANGO_ALLOWED_HOSTS lists exact hostnames. Never *.
• DJANGO_CORS_ALLOWED_ORIGINS lists exact origins. Never *, and never a private LAN address in a public deployment.
• python manage.py check --deploy reports no issues.

• The service is behind HTTPS, with DJANGO_SECURE_SSL_REDIRECT=1.
• If a reverse proxy terminates TLS, it sets X-Forwarded-Proto — the application trusts that header via SECURE_PROXY_SSL_HEADER.
• HSTS (DJANGO_SECURE_HSTS_SECONDS) is enabled only once HTTPS is confirmed working, since it is hard to undo in browsers.

• API_ANON_THROTTLE_RATE is tuned for your traffic. The endpoint is unauthenticated and every request costs a Groq API call, so an open instance is a direct billing risk.
• GRAMMAR_MAX_INPUT_CHARS is set to the smallest value you need.
• Consider putting authentication or a WAF in front of a public deployment.

• Confirm your logging stack is not configured to record request bodies. The application deliberately does not log user text or IP addresses (see Privacy); a proxy or APM agent can reintroduce that.
• Understand that submitted text is sent to Groq for processing. Review their data policy before handling confidential material.

• Images are rebuilt regularly to pick up base-image security updates.
• Containers run as the non-root user defined in the Dockerfiles — do not override with user: root.