Strapi Security Scanner — Find public collection-type leaks

Strapi's Public role permissions are a footgun. Every Strapi quickstart I've seen leaves find and findOne enabled on Users so the example login flow works — and that exact setting often ships to production unchanged. Anyone with your Strapi URL can list every user's email, role, and metadata. This actor finds those leaks in 30 seconds.

Probes a public Strapi instance for content-types readable by the Public role. Sends /api/{collection}?pagination[limit]=1 (v4+) and /{collection}?_limit=1 (v3) per content-type. Returns table-level counts + a verbatim curl reproducer per finding. Counts only — never row data.

💸 Found a leak? I do turnkey Strapi audits + Public-role hardening for $99 (Stripe — 48h, money-back if nothing actionable). Or $29/mo weekly auto-scans at rls-monitor.vercel.app.

⭐️ Solo dev competing with bigger Apify publishers. A 30-second review is the single thing that lifts ranking. Thank you.

Why this exists

Strapi exposes every content-type as a REST endpoint at /api/<collection> (v4+) or /<collection> (v3). The thing keeping records private is the Public role's permissions: if find or findOne is checked for a content-type, every visitor can list and read those records — no auth, no API token.

The Strapi admin UI makes it very easy to leave Public permissions on:

1. Tutorials usually grant Public find to demo content rendering, but the warning to disable later is rarely seen
2. Adding a new content-type doesn't reset Public — fields from the old configuration carry over
3. users-permissions/users is the worst offender: the plugin ships with Public find so the login flow can verify a user exists, but most operators never tighten this

This scanner probes ~30 common content-type names (plus any you pass as hints), pluralized both ways. Each one is checked at both v4 and v3 endpoints.

How to run

Either:

1. Leave inputs empty + click Run for a DEMO sample report (so you can see what a real scan returns)
2. Provide your strapiUrl to scan your actual instance

{
  "strapiUrl": "https://api.your-domain.com",
  "collectionHints": ["my-secret-content-type", "subscribers-v2"],
  "outputFormat": "both"
}

What you get

• HTML report (report.html in the run's key-value store): a self-contained page with letter findings, severity table, copy-pasteable curl reproducers, and the exact Strapi admin steps to fix each one
• Dataset rows: one structured row per finding (name, total, severity, sensitiveColumns, reproducer, version)

Sample finding

[CRITICAL] users — readable by Public role
Total records: 4,231
Sample columns: id, username, email, provider, confirmed, blocked, role
Sensitive columns detected: email

Reproducer:
curl 'https://api.your-domain.com/api/users?pagination[limit]=1' -I

How to fix (free, ~5 min)

In your Strapi admin panel:

1. Go to Settings → Users & Permissions Plugin → Roles → Public
2. For each leaky content-type, uncheck the find and findOne permissions
3. Click Save
4. Re-run this scanner to confirm zero anon-readable content-types

If a content-type should be public (blog posts, product catalog), audit the fields exposed — use the content-type's Privacy settings to hide sensitive columns from Public responses.

Ethical use

• Only scan instances you own or have explicit permission to scan
• Probe queries use ?pagination[limit]=1 to confirm exposure without exfiltrating contents
• Counts are derived from Strapi's pagination metadata, not row reads

Related

• Stripe audit ($99 one-time): buy.stripe.com/00w9AT9TWdaW7yx9KkcAo01
• Weekly auto-scans ($29/mo): rls-monitor.vercel.app
• Sister scanners: Supabase, Firebase, Strapi, Directus, Payload CMS, Convex, Hasura, PocketBase, Appwrite, Nhost.

Built by Renzo.