Benito Rodríguez
ce54db38d9
- 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
100 lines
3.1 KiB
Markdown
100 lines
3.1 KiB
Markdown
# 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 credentials
|
|
- `RAWG_API_KEY` — RAWG API key (rate limited)
|
|
- `THEGAMESDB_API_KEY` — TheGamesDB key
|
|
- `DATABASE_URL` — SQLite file path (contains password if using remote DB)
|
|
|
|
### Best Practices
|
|
|
|
1. Use `.env.local` or `.env.{NODE_ENV}.local` for local development
|
|
2. Never log or print secrets
|
|
3. Use GitHub/Gitea Secrets for CI/CD pipelines
|
|
4. Rotate keys regularly
|
|
5. 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
|
|
|
|
1. Go to your Gitea repository settings
|
|
- Navigate to: `https://your-gitea-instance/your-org/quasar/settings/secrets/actions`
|
|
2. 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
|
|
3. Commit `.gitea/workflows/ci.yml` to 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/*.ts` define 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
|