If you discover a security vulnerability in AstraQ, please report it responsibly:

1. Do not open a public GitHub issue for security vulnerabilities.
2. Email the maintainers at a6hinandh@gmail.com with:
   • A description of the vulnerability
   • Steps to reproduce
   • Potential impact assessment
3. You will receive an acknowledgment within 48 hours.

• Firebase ID tokens are verified server-side with check_revoked=True on every request
• All user data is scoped by Firebase Auth UID — no cross-user data access is possible
• Rate limiting (per-user sliding window) prevents brute-force and abuse

• Service account keys are never included in the Docker image
• .env, key files, and credentials are in .gitignore and .dockerignore
• Production credentials are injected via environment variables (FIREBASE_SERVICE_ACCOUNT_B64)
• CI includes a secret-scanning step that fails the build if credentials are detected

• All request bodies are validated via Pydantic models with strict typing
• Chat messages are capped at 4000 characters
• File uploads are restricted to PDF/DOCX/TXT, max 10 MB, max 50 PDF pages
• Query parameters are URL-decoded and sanitized before use

• Retrieved RAG context is sanitized before injection into Gemini prompts
• Prompt injection guards are applied to user-supplied document text
• LLM responses are treated as untrusted content for rendering purposes

• CORS is restricted to explicitly configured frontend origins only
• Security headers (X-Content-Type-Options, X-Frame-Options, etc.) are set via middleware
• Request-ID propagation for audit trails without logging PII

• No user message content is included in application logs
• Structured logging uses request-IDs for tracing without exposing sensitive data
• File uploads are processed transiently — extracted text is returned to the client, not stored

We use pip-audit and Dependabot to monitor for known vulnerabilities in dependencies. The requirements.txt is kept minimal to reduce attack surface.