Security
The analyzer is designed so GitHub credentials and server-side logic stay behind the API boundary.
Security Measures
| Measure | Implementation |
|---|---|
| Security headers | X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy, and Permissions-Policy configured in Next.js |
| Input sanitization | Every incoming repository URL is validated and sanitized server-side |
| No secret exposure | GITHUB_TOKEN stays in the service layer only |
| Reduced fingerprinting | poweredByHeader: false removes the default Next.js header |
| Render safety | User-visible data is rendered through React without raw HTML injection |
| Error isolation | Unexpected server failures are converted to generic error responses |
| Safe external links | External GitHub links use rel=“noopener noreferrer” and open in a new tab |
Threat Model Assumptions
- Repository URLs are untrusted input.
- Upstream GitHub API failures are normal and must degrade safely.
- Browser users should never receive backend secrets or internal stack traces.
Practical Notes
If you are presenting the tool publicly, the most important operational controls are:
- Validate every repository URL on both client and server.
- Keep the token server-only.
- Fail with structured messages instead of raw exception details.
Limitations
Some limits are inherent to the product model:
- Stars and forks are proxies for visibility, not code quality.
- Commit volume can be distorted by squash merges or monorepo workflows.
- Dependency count is precise for Node.js but estimated for many other ecosystems.
- Serverless cold starts reset the in-memory cache.