Directus Security Scanner — Find public-role collection leaks

Directus ships with a "Public" role enabled by default, and the only thing keeping your collections private is the read permissions assigned to it. Most operators tighten Public on their main content collections but forget the internal ones — directus_users, directus_files, and any custom table created via the admin UI. This actor finds those leaks in 30 seconds.

Probes a public Directus instance for collections readable by the Public role. Sends /items/{collection}?limit=1&meta=total_count per collection. Returns row counts + a verbatim curl reproducer per finding. Counts only — never row data.

💸 Found a leak? I do turnkey Directus 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

Directus's REST API exposes every collection at /items/<name>. The Public role's read permission is what decides who can list a collection without authenticating. Most Directus tutorials walk through enabling Public read on a demo collection (e.g., articles) and then forget to mention that the Public role persists across schema changes — so when you add a new collection it inherits no permission, but the patterns established by tutorial code often grant Public access opportunistically.

The biggest landmines:

1. directus_users — if Public read is on, every internal user's email, role, status, and login token field metadata is listable
2. directus_files — file metadata + download URLs leak even when individual files require auth
3. Custom collections cloned from a "public" template — the Public-role read permission carries over silently

This scanner probes ~35 collection names (common business names plus Directus system tables) plus any you pass as hints.

How to run

Either:

1. Leave inputs empty + click Run for a DEMO sample report
2. Provide your directusUrl to scan your actual instance

{
  "directusUrl": "https://directus.your-domain.com",
  "collectionHints": ["my-custom-collection"],
  "outputFormat": "both"
}

What you get

• HTML report in the run's key-value store: severity-coded findings, copy-pasteable curl reproducers, exact Directus admin steps to fix
• Dataset rows: one structured row per finding

Sample finding

[CRITICAL] directus_users — readable by Public role
Total records: 1,284
Sample columns: id, first_name, last_name, email, password, role, status, token, last_access
Sensitive columns detected: email, password, token

Reproducer:
curl 'https://directus.your-domain.com/items/directus_users?limit=1' -I

How to fix (free, ~5 min)

1. Open Directus admin → Settings → Access Control
2. Click the Public role
3. For each leaky collection, set the read permission to No Access
4. Click Save on each change
5. Re-run this scanner to confirm zero anon-readable collections

If a collection should be public (blog content, marketing pages), set read to Custom Access and use field-level rules to hide sensitive columns from anon responses.

Ethical use

• Only scan instances you own or have explicit permission to scan
• Probe queries use ?limit=1&meta=total_count to confirm exposure without exfiltrating contents

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.