Description
The Socket badge API endpoint (https://socket.dev/api/badge/npm/package/<name>) is returning a Cloudflare challenge page (403) instead of the SVG badge. This breaks badge rendering on GitHub READMEs and any automated badge consumers.
Steps to reproduce
curl -sI "https://socket.dev/api/badge/npm/package/kastell"
# Returns: HTTP/1.1 403 with Cloudflare challenge HTML
Expected behavior
The badge endpoint should return an SVG image without requiring JavaScript/cookie-based Cloudflare verification, since badge consumers (GitHub camo proxy, shields.io, CI tools) cannot execute JavaScript.
Actual behavior
- GitHub README shows a stale/cached badge or "in progress" text
curl and other HTTP clients receive a 403 with Cloudflare challenge page
- The socket.dev website itself shows the correct score (e.g., 73 for
kastell)
Environment
- Package:
kastell (npm)
- Badge URL:
https://socket.dev/api/badge/npm/package/kastell
- Tested from multiple locations and user agents
Suggestion
Consider allowlisting the /api/badge/ path from Cloudflare's managed challenge, similar to how shields.io and other badge services handle their SVG endpoints.
Description
The Socket badge API endpoint (
https://socket.dev/api/badge/npm/package/<name>) is returning a Cloudflare challenge page (403) instead of the SVG badge. This breaks badge rendering on GitHub READMEs and any automated badge consumers.Steps to reproduce
Expected behavior
The badge endpoint should return an SVG image without requiring JavaScript/cookie-based Cloudflare verification, since badge consumers (GitHub camo proxy, shields.io, CI tools) cannot execute JavaScript.
Actual behavior
curland other HTTP clients receive a 403 with Cloudflare challenge pagekastell)Environment
kastell(npm)https://socket.dev/api/badge/npm/package/kastellSuggestion
Consider allowlisting the
/api/badge/path from Cloudflare's managed challenge, similar to how shields.io and other badge services handle their SVG endpoints.