# Security Policy ## Supported Versions This project is actively maintained. Security updates will be provided for the latest release on the `main` branch. | Version | Supported | | ------- | ------------------ | | main | :white_check_mark: | | < main | :x: | ## Reporting a Vulnerability We take the security of this CV site seriously. If you discover a security vulnerability, please help us protect users by following responsible disclosure practices. ### How to Report **DO NOT** open a public issue for security vulnerabilities. Instead, please report security vulnerabilities by: 1. **GitHub Security Advisories** (Preferred): - Go to the repository's Security tab - Click "Report a vulnerability" - Fill out the form with details 2. **Direct Contact**: - Open a private issue or contact the maintainer directly - Use encrypted communication if the vulnerability is severe ### What to Include Please provide the following information in your report: - **Description** of the vulnerability - **Steps to reproduce** the issue - **Potential impact** (e.g., data exposure, XSS, CSRF) - **Affected versions** (if known) - **Suggested fix** (if you have one) - **Your contact information** for follow-up questions ### Response Timeline - **Initial Response**: Within 48 hours - **Status Update**: Within 7 days - **Fix Timeline**: Depends on severity - Critical: Within 7 days - High: Within 14 days - Medium: Within 30 days - Low: Next release cycle ### Disclosure Policy - We ask that you give us reasonable time to fix the vulnerability before public disclosure - We will credit you in the security advisory (unless you prefer to remain anonymous) - Once the fix is deployed, we will publish a security advisory with details ## Security Considerations for Deployments If you're deploying this CV site, please be aware of these security considerations: ### 1. PDF Generation Security The server uses headless Chrome (via chromedp) to generate PDFs: - **Risk**: Chromedp executes JavaScript and renders HTML, which could be exploited if user input is not sanitized - **Mitigation**: - The CV data comes from trusted JSON files, not user input - If you modify the application to accept user input, ensure proper sanitization - Consider running chromedp in a sandboxed environment ### 2. Content Security Policy The application includes CSP headers: ```go Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://unpkg.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: ``` - Review and adjust CSP headers based on your deployment needs - Remove `'unsafe-inline'` if possible by moving inline scripts/styles to separate files ### 3. Environment Variables Sensitive configuration is managed via environment variables: - **Never commit** `.env` file to version control - Use `.env.example` as a template - In production, use secure secret management (e.g., HashiCorp Vault, AWS Secrets Manager) ### 4. HTTPS in Production - **Always use HTTPS** in production - Configure TLS certificates (Let's Encrypt recommended) - Consider using a reverse proxy (nginx, Caddy) for TLS termination ### 5. Rate Limiting The application does not include built-in rate limiting: - **Recommendation**: Use a reverse proxy (nginx, Caddy) to implement rate limiting - Protect the `/export/pdf` endpoint to prevent PDF generation abuse ### 6. Input Validation While this application primarily serves static CV data: - If you extend it to accept user input, implement strict validation - Sanitize all inputs before rendering in templates - Use Go's `html/template` package (which auto-escapes) for HTML rendering ### 7. Dependency Management Keep dependencies up to date: ```bash # Check for outdated dependencies go list -u -m all # Update dependencies go get -u ./... go mod tidy ``` ### 8. Security Headers The application sets security headers: - `X-Content-Type-Options: nosniff` - `X-Frame-Options: DENY` - `X-XSS-Protection: 1; mode=block` - `Content-Security-Policy: ...` Review and enhance these headers based on your deployment needs. ### 9. Logging and Monitoring - Enable structured logging in production - Monitor for unusual patterns (e.g., excessive PDF generation requests) - Set up alerts for errors and anomalies ### 10. Docker Security If deploying via Docker: - Use official, minimal base images - Run container as non-root user - Scan images for vulnerabilities (e.g., `docker scan`, Trivy) - Keep base images updated ## Known Security Considerations ### PDF Generation Resource Usage - **Issue**: PDF generation uses headless Chrome, which consumes significant CPU/memory - **Impact**: Potential DoS via excessive PDF generation requests - **Mitigation**: - Implement rate limiting on `/export/pdf` endpoint - Consider caching generated PDFs - Monitor resource usage ### Third-Party Dependencies External dependencies loaded from CDNs: - HTMX from `https://unpkg.com` - Google Fonts from `https://fonts.googleapis.com` **Recommendation**: For production, consider: - Self-hosting these dependencies for better control - Using Subresource Integrity (SRI) hashes - Implementing a Content Security Policy ## Security Best Practices If you're forking this project for your own CV: 1. **Review all code** before deploying 2. **Update personal information** in JSON files 3. **Configure security headers** appropriate for your use case 4. **Enable HTTPS** with valid certificates 5. **Keep dependencies updated** regularly 6. **Monitor application logs** for suspicious activity 7. **Backup your data** regularly 8. **Test security** before going live ## Security Updates Security updates will be announced via: - GitHub Security Advisories - Release notes on GitHub - Git commit messages tagged with `[SECURITY]` ## Contact For security concerns, please contact the project maintainer via GitHub. ## Acknowledgments We appreciate the security research community's efforts in responsibly disclosing vulnerabilities. Thank you for helping keep this project secure!