Vulnerability Disclosure Program

Our commitment

We treat good-faith security research as a favor, not a threat. If you follow the guidelines on this page, we will work with you in good faith to understand and resolve the issue quickly, and we will not pursue legal action against you for that research.

Scope

In scope:

• The Credit Defense Hub website at creditdefensehub.com and its subdomains.
• The Site’s own code and configuration. Examples: a way to bypass or disable our security headers; a cross-site scripting or injection flaw in a page or calculator; a way to make a client-side tool, like the debt tracker, leak data it shouldn’t; or a misconfiguration that exposes source files, backups, or server details.
• Any sign that our admin or API endpoints are reachable in production. Those are intentionally removed from the production build and should not exist on the live site at all. If you find one, that’s high priority — please report it right away.

Out of scope:

• Third-party services we merely embed or link to, such as Google Analytics, Google Fonts, logo.dev, or any card issuer’s or lender’s own website. Report those issues directly to the company that owns them, not to us.
• Findings that need a physically stolen or already-compromised device, or that only work on outdated, unsupported browsers.
• Purely theoretical issues with no real path to impact, headers we’ve already documented as intentionally absent, and raw scanner output with no manual verification.

Safe harbor

We will not pursue legal action against researchers who act in good faith under this policy. That means: test only against your own accounts or clearly simulated data; avoid privacy violations and service disruption; report promptly; and give us a fair chance to fix the issue before you disclose it publicly (see “Coordinated disclosure” below). If a third party ever brings a claim against you for research that followed this policy, we will state clearly — to that party or in any proceeding — that your activity was authorized.

Testing that is never authorized

Regardless of scope, the following are always prohibited:

• Social engineering — phishing, pretexting, or otherwise trying to trick our contributors, our contacts, or our visitors into giving up information or access;
• Denial-of-service testing — load testing, flooding, or any attempt to degrade the Site’s availability for other visitors;
• Accessing, modifying, or exfiltrating data that isn’t yours — including any real visitor data you might encounter unexpectedly; stop immediately and report it rather than continuing to explore it; and
• Physical attacks — against our offices, contributors, or any hosting provider’s facilities.

How to report

We don’t maintain a dedicated security mailbox today, so please report through our contact page and mark your message as a security report. Include as much of the following as you can:

• A clear description of the issue and its potential impact;
• The exact URL(s) or feature affected;
• Step-by-step instructions to reproduce it;
• Any proof-of-concept, screenshots, or request/response details; and
• Your browser and operating system, if relevant.

What happens after you report

We aim to acknowledge new reports within five business days. While we investigate, we aim to update you at least every two weeks. That’s a goal we are committing to, not a legal guarantee — we’re a small team. We’ll let you know once a fix ships.

Recognition, not a bounty

We do not currently run a paid bug bounty program, and reporting an issue does not entitle you to payment. What we do offer: our thanks, a direct line to whoever fixes the issue, and — with your permission, once a fix has shipped — public credit for the finding.

Coordinated disclosure

Please give us a reasonable window to investigate and fix a reported issue — 90 days is our general target — before disclosing it publicly, and coordinate the timing and details of any public write-up with us in advance. We’ll move as fast as the fix allows and will tell you if we need more time and why.