cv-site/doc/SECURITY.md

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	✅
< main	❌

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:

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:

# 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!