- Supported Versions
- Reporting a Vulnerability
- Response Timeline
- Security Measures
- Scope
- Known Limitations
- Security Headers
- Responsible Disclosure
| Version | Status | Notes |
|---|---|---|
2.0.x |
β Active support | Security patches applied promptly |
1.x |
β End of life | No longer receives updates |
We recommend always running the latest version. Check your version at /api/v1/health.
π Please do NOT open a public GitHub issue for security vulnerabilities.
- Go to GitHub Security Advisories
- Click "New draft security advisory"
- Fill in the details using the template below
| Field | Description |
|---|---|
| Description | Clear explanation of the vulnerability |
| Steps to Reproduce | Numbered steps to trigger the issue |
| Impact | What an attacker could achieve |
| Affected Endpoint(s) | Which API routes are involved |
| Proof of Concept | Request/response examples (redact any real data) |
| Suggested Fix | If you have ideas for remediation |
| Your Contact | So we can follow up with questions |
The following are not security vulnerabilities:
- Rate limiting being too restrictive
- Upstream data accuracy issues (contact Toraka instead)
- Missing features or API enhancements
- Deprecation warnings in dependencies
| Phase | Target |
|---|---|
| Acknowledgment | Within 48 hours |
| Initial Assessment | Within 1 week |
| Critical Fix | Within 24 hours |
| High Severity Fix | Within 1 week |
| Medium/Low Fix | Next release cycle |
| Public Disclosure | After fix is deployed |
We will keep you informed of progress via the security advisory. If we cannot fix an issue promptly, we'll explain why and provide a timeline.
- 60 requests per minute per IP address (sliding window)
- Rate limit headers on every response (
X-RateLimit-Limit,X-RateLimit-Remaining) 429 Too Many RequestswithRetry-Afterheader when exceeded
- All query parameters validated before processing
- Slugs are normalized and sanitized (no path traversal, no injection)
- Search queries have a minimum length requirement (2 characters)
- Integer parameters bounds-checked (page, limit)
- HTTPS only β HTTP requests auto-redirect to HTTPS
- CORS β Configured for public API access (
Access-Control-Allow-Origin: *) - Security headers on all responses (see below)
- No authentication β No user credentials, tokens, or PII stored
- No user accounts β No registration, login, or user data collection
- Cache only β In-memory cache with automatic TTL expiration
- Upstream isolation β Toraka API keys/credentials are server-side only, never exposed to clients
- Vercel deployment β Automatic HTTPS, DDoS protection, edge caching
- GitHub Actions CI β Automated lint and build checks on every PR
- Dependency scanning β Dependabot configured for automatic security updates
Every API response includes:
| Header | Value | Purpose |
|---|---|---|
X-Content-Type-Options |
nosniff |
Prevents MIME type sniffing |
X-Frame-Options |
DENY |
Prevents clickjacking |
Referrer-Policy |
strict-origin-when-cross-origin |
Controls referrer information |
Access-Control-Allow-Origin |
* |
CORS (public API) |
Access-Control-Allow-Methods |
GET, OPTIONS |
Only GET requests allowed |
X-Powered-By |
ShineiAPI v2.0.2 |
API identification |
X-RateLimit-Limit |
60 |
Rate limit transparency |
X-Request-ID |
uuid |
Request tracing |
Everything hosted under github.com/Shineii86/ShineiAPI:
- API route handlers (
src/app/api/) - Middleware (
src/middleware.js) - Cache layer (
src/lib/cache.js) - Toraka client (
src/lib/toraka.js) - Constants and configuration (
src/lib/constants.js) - Response helpers (
src/lib/response.js) - Frontend components and pages (
src/app/,src/components/) - Public assets (
public/) - Deployment config (
vercel.json)
| Item | Why |
|---|---|
| Toraka API | Third-party service with its own security policy |
| Vercel platform | Managed by Vercel |
| GitHub platform | Managed by GitHub |
| User-deployed instances | Self-hosted deployments are the operator's responsibility |
| Dependencies with known CVEs | Report to the upstream project; we'll update when patches are available |
These are architectural trade-offs, not vulnerabilities:
| Limitation | Explanation |
|---|---|
| Public API, no auth | All data is publicly accessible by design |
| Upstream dependency | If Toraka is down, ShineiAPI returns 502/503 |
| In-memory cache | Cache resets on serverless cold starts (Vercel) |
| Rate limit per IP | Shared IPs (VPNs, NAT) may hit limits faster |
| CORS wildcard | Any origin can make requests (intentional for public API) |
We believe in responsible disclosure and will:
- β Credit reporters in the fix announcement (unless they prefer anonymity)
- β Communicate openly about timelines and progress
- β Not take legal action against researchers who follow this policy
- β Work with you to understand and validate the issue
contributors who responsibly disclosed vulnerabilities will be listed here
- π Security reports: GitHub Security Advisories
- π¬ General questions: GitHub Discussions
- π Non-security bugs: GitHub Issues
Thank you for helping keep ShineiAPI and its users safe! π‘οΈ