Security policy

Last updated 2026-04-20 · security.txt

Banned Index takes security seriously. If you’ve found a vulnerability — a way to access data you shouldn’t, modify records you shouldn’t, crash the site, or abuse our forms — we want to hear about it, and we’ll treat you well.

Reporting

Email security@bannedindex.org with:

• A description of the issue
• Steps to reproduce (if applicable)
• A proof-of-concept, sample URL, or screenshot (if applicable)
• Your name or handle, if you’d like credit

Encrypted email is welcome but not required.

Please do NOT:

• Post the vulnerability publicly before we’ve had a chance to fix it
• Attempt to access or modify data belonging to other users
• Run automated scanners against production beyond light rate-limited probing
• Use DoS or DDoS as part of a proof-of-concept

Do feel free to:

• Probe public pages at a modest pace
• Test the public correction / contribute forms with clearly-fake data
• Read /.well-known/security.txt for machine-readable contact info

Our commitment

• Initial response within 7 days of your report
• Status updates every 14 days while we investigate
• Credit on the site and in the commit log if you want it (and your report led to a fix)
• No legal action against researchers who follow this policy in good faith

Scope

In scope:

• bannedindex.org — the production site
• The admin portal (authenticated; URL shared on request)
• Public API endpoints (when launched)
• The source code at github.com/lhartup/banned-index

Out of scope:

• Third-party services we depend on (Vercel, Supabase, Resend, GitHub, OpenLibrary, ISBNdb, Wayback Machine) — report directly to those providers
• Social engineering of project maintainers
• Physical security

Priority

High (immediate): authentication bypass, data exfiltration beyond public data, arbitrary code execution, destructive writes by unauthorized users, widespread PII leak.

Medium (within a week): limited data exposure, stored XSS, server-side request forgery, rate-limit bypass enabling spam/abuse.

Low (when convenient): missing security headers, CSRF on non-sensitive actions, self-XSS, verbose error messages.

Acknowledgments

None yet. You could be first.