How We Secure HobbyCardIndex

The headline number

The composite is 9.05 out of 10, aggregated from sixteen categories at equal weighting. Our target for launch readiness is 9.5. The current posture is not yet where we want to ship, but it is substantially ahead of where it was in mid-April (prior composite 7.18). The gain came from wiring defense-in-depth primitives that were partially complete into coherent chains: Row Level Security, tiered admin isolation, per-user rate limiting, two-factor authentication with fail-closed semantics, and parameterized database access everywhere. The gap between 9.05 and 9.5 is not architectural. It is a short list of infrastructure hardening items listed in the roadmap section below.

This page is a plain-language summary, not a vulnerability disclosure. We reference findings at the category level only; no file paths, endpoint behaviors, or proof-of-concept code. The full attack plan is internal-only. If you believe you have found an issue, the responsible disclosure section below tells you how to reach us.

Category-by-category breakdown

Each category below covers what the control is, how we scored it, and what an average collector should take away. We use a 1 to 10 scale with equal weighting across categories. The individual numbers come from the April 2026 audit checklist.

Authentication and session management

Passwords require ten characters minimum with mixed case and a number. We reject twenty common weak passwords and check every new password against HaveIBeenPwned via the k-anonymity API so we never see the password itself. Login is capped at ten attempts per fifteen minutes per IP; signup at five per hour per IP. Session tokens carry a version number we bump on password change or forced logout, which invalidates every outstanding token for that user immediately.

Authorization and Row Level Security

Thirty-eight user-owned database tables are protected by Postgres Row Level Security. Each table has three policies: the owning user can read and write their rows, an admin bypass for support, and a background-job policy for scheduled updates. The application sets a per-request user context that the database enforces. Admin routes use a two-layer check: a token claim verified against a fresh database lookup, with destructive endpoints going through a stricter DB-only check.

Input validation, XSS, and CSRF

Every route validates URL parameters against an explicit pattern (numeric IDs bounded to signed-integer range, string IDs to a safe character set). The request-body sanitizer recursively strips HTML tags, javascript-scheme URIs, and event-handler attributes. Client-side user-rendered HTML passes through DOMPurify. State-changing requests require a CSRF token sent both as a cookie (sameSite strict, 24-hour lifetime) and as a header, compared server-side.

Rate limiting and file uploads

Three rate-limit layers sit in series: a global IP limiter, auth-specific limiters on login and signup, and a per-user DB-tracked limiter that enforces tier-appropriate ceilings. Uploads are held in memory, capped at 5 MB per file and 3 files per request, and MIME-filtered to JPEG, PNG, and WebP. The audit flagged that MIME type is client-spoofable, which is why the pre-launch roadmap includes magic-byte verification plus a ClamAV antivirus sidecar.

Secrets, transport, and logging

On boot, the application validates every required secret against minimum length and a banned-default list. If any secret is missing, short, or matches a known default, the application refuses to start in production. Encryption keys for stored OAuth tokens are derived via HKDF from a master key that lives in an environment variable, not in the database. Database connections use TLS today; full chain certificate verification against the managed Postgres certificate authority is on the pre-launch list. Structured logs carry a correlation ID through every request with automatic redaction of sensitive headers.

What we use internally vs what ships to users

A security posture is the set of controls that actually protect a user, not the set of controls that exist somewhere. The table below separates what runs in the production path from what is internal-only tooling, so that the scorecard above is grounded in the user-facing surface.

Payments deserve a specific call-out because it is the item collectors ask about most often. HCI does not store credit card numbers, CVVs, or full billing details. The checkout flow is a redirect to Stripe Checkout, and what returns is a customer reference ID plus tier state via webhook. A breach of HCI would not expose payment card data because payment card data does not live here.

Responsible disclosure

If you believe you have found a security issue, email [email protected] with a description of the issue, the affected URL or endpoint, and reproduction steps if you have them. Please do not post details publicly before we have a chance to respond.

Scope covers hobbycardindex.com and its subdomains. We will acknowledge receipt within three business days and will keep the reporter informed as a fix ships. HCI is a small team and does not currently run a paid bug bounty, but with your consent we will credit responsible disclosures on this page and in our release notes. Out-of-scope items include social engineering, denial-of-service testing against production, and any action that would affect another user's data.

What is still on the roadmap before public launch

Four items are tracked against the 9.5 target. All four are scoped and on the sprint plan.

• Database transport SSL verification. Upgrade the database client configuration from permissive verification to full chain verification against the managed Postgres certificate authority. Must land before the first external connection to the production database.
• ClamAV antivirus sidecar on uploads. Run the contents of every uploaded image buffer through ClamAV before accepting it into the scan pipeline. Combined with magic-byte MIME-type verification on the buffer itself, this closes the "spoofed content-type" gap that today the static MIME filter cannot catch.
• Secrets migration from plaintext .env to the hosting provider's encrypted environment variable store. Production secrets today live in a chmod-600 .env file on the host. The pre-launch step moves them into the provider's encrypted variable store so that a droplet snapshot alone would not expose them.
• Row Level Security role confirmation. Postgres enforces RLS strictly only for non-superuser database roles. The pre-launch task confirms the production database role is non-superuser and applies FORCE ROW LEVEL SECURITY on the protected tables as a belt-and-suspenders measure.

A second tier of items is on the first-ninety-days list: client session tokens migrated from browser storage to HTTP-only cookies, a dedicated security-events table with alerting on anomalous authentication patterns, backup codes for two-factor authentication recovery, and offsite database backups with a ninety-day retention window. Real improvements, but not launch gates.

Bottom line for collectors

HCI is a small independent team that takes security seriously enough to run a formal internal audit, publish the score, and ship the hardening work on a calendar. The current 9.05 composite reflects a stack with defense-in-depth primitives in place across authentication, authorization, input validation, transport, and session management. The remaining work to reach 9.5 is scoped infrastructure hardening rather than architectural rework.

If you store a card collection on HCI, the controls that matter most to you are: Row Level Security at the database layer protecting your rows from other users, bcrypt plus HIBP on your password, instant token invalidation when you change your password, two-factor authentication available on every account and required for admin and dealer tiers, and Stripe handling all payment data so a breach here does not expose card numbers.