- Create .gitea/workflows/ci.yml with 4 sequential jobs - lint: Run ESLint on root configuration - test-backend: Run backend Vitest tests with SQLite - test-frontend: Run frontend Vitest tests - test-e2e: Run Playwright E2E tests (bloqueante) - E2E job automates server startup + Playwright test execution - Configure Gitea Secrets for IGDB, RAWG, TheGamesDB API keys - Add artifact upload for Playwright reports on failure - Update SECURITY.md with CI/CD Secrets setup instructions - Update docs/API_KEYS.md with production Gitea workflow guide - Add tests/gitea-workflow.spec.ts with 12 validation tests - Workflow triggers on push/PR to main and develop branches
3.1 KiB
3.1 KiB
Security Policy
Reporting Security Vulnerabilities
If you discover a security vulnerability in Quasar, please email security@quasar.local with:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
We'll acknowledge your report within 48 hours and work on a fix.
Environment Variables & Secrets
IMPORTANT: Never commit .env files to the repository.
Sensitive Variables
IGDB_CLIENT_ID,IGDB_CLIENT_SECRET— Twitch OAuth credentialsRAWG_API_KEY— RAWG API key (rate limited)THEGAMESDB_API_KEY— TheGamesDB keyDATABASE_URL— SQLite file path (contains password if using remote DB)
Best Practices
- Use
.env.localor.env.{NODE_ENV}.localfor local development - Never log or print secrets
- Use GitHub/Gitea Secrets for CI/CD pipelines
- Rotate keys regularly
- Use separate keys for development, staging, production
CI/CD Secrets (Gitea Actions)
For automated testing in Gitea Actions, store API keys as repository secrets:
Setup Instructions
- Go to your Gitea repository settings
- Navigate to:
https://your-gitea-instance/your-org/quasar/settings/secrets/actions
- Navigate to:
- Click "New Secret" for each credential:
- Name:
IGDB_CLIENT_ID→ Value: Your Client ID from Twitch - Name:
IGDB_CLIENT_SECRET→ Value: Your Client Secret from Twitch - Name:
RAWG_API_KEY→ Value: Your RAWG API key - Name:
THEGAMESDB_API_KEY→ Value: Your TheGamesDB API key
- Name:
- Commit
.gitea/workflows/ci.ymlto trigger CI pipeline
How Secrets Are Used
The CI workflow (.gitea/workflows/ci.yml) automatically:
- Runs lint on every push and pull request
- Runs backend tests (Vitest) with
DATABASE_URL=file:./test.db - Runs frontend tests (Vitest)
- Runs E2E tests (Playwright) with API key secrets injected as environment variables
- Fails the build if any tests fail (prevents broken code from being merged)
Security Notes
- Secrets are encrypted at rest in Gitea
- Secrets are masked in logs (never printed to console)
- Only accessible in CI/CD contexts (not in local development)
- Same secrets work for both testing and production deployments
Input Validation & Sanitization
All user inputs are validated using Zod schemas:
- Backend:
src/validators/*.tsdefine strict schemas - Frontend: React Hook Form + Zod validation
- Game titles, ROM file paths, and user uploads are sanitized
Rate Limiting
API calls to metadata services are rate-limited:
- IGDB: 4 requests/second
- RAWG: 20 requests/second (free tier)
- TheGamesDB: 1 request/second
Database Security
SQLite is used for MVP. For production:
- Consider PostgreSQL or MySQL
- Enable encrypted connections (SSL/TLS)
- Use connection pooling (current: Prisma with pool settings)
- Regular backups
CORS & CSP
Configure appropriate CORS headers in backend:
- Frontend origin:
http://localhost:3000(dev),https://yourdomain.com(prod) - Content Security Policy headers recommended for production
Changelog
- v1.0.0 (2026-02-12): Initial security guidelines