Skip to content
HoldingCost

Security policy

Last updated:

1. Overview

HoldingCost is a static calculator platform. We do not operate a backend API, user account system, or payment processing — the attack surface is correspondingly narrow. Nevertheless, we take security reports seriously and are grateful to researchers who identify and responsibly disclose issues.

This page describes how to contact us, what information to include, what we consider in-scope, and what we commit to doing in response. Our machine-readable disclosure file lives at /.well-known/security.txt.

2. How to report an issue

Send your report to security@holdingcost.com. Please include as much of the following as you can:

  • Affected URL or asset — the specific page, file, or endpoint where you found the issue.
  • Steps to reproduce — a clear, minimal sequence that reliably triggers the behaviour.
  • Potential impact — what an attacker could achieve by exploiting this issue.
  • Your contact details — so we can follow up if we need clarification.

You do not need to use a specific template. A clear plain-text email is fine. Proof-of-concept code or screenshots are welcome where they help illustrate the issue.

3. What happens next

We will aim to acknowledge your report within 5 business days. After that, we will:

  • Investigate and confirm whether the behaviour is a valid security issue.
  • Keep you informed of our progress where possible.
  • Work to remediate confirmed issues as quickly as the severity warrants.

We ask that you give us a reasonable time to fix the issue before any public disclosure. For most issues, 90 days from our confirmation is a widely accepted baseline. We will negotiate in good faith if you believe a shorter timeline is warranted by the severity.

4. Out of scope

The following issues are generally not considered in scope for a security report:

  • Theoretical attacks without a working proof of concept — please demonstrate the impact, not just the possibility.
  • Social engineering — phishing, pretexting, or other human-manipulation techniques targeting our team or users.
  • Rate-limiting and denial-of-service findings — our platform is served via Cloudflare's global edge network; report volumetric or resource-exhaustion issues to Cloudflare directly.
  • Issues in third-party services we do not control — Google Analytics, Google AdSense, and Cloudflare are maintained by their respective vendors. Report issues in those services directly to them.
  • Missing security headers on embed pages — embed pages (/embed/*) intentionally use relaxed frame-ancestors headers to allow embedding in third-party sites. This is expected behaviour.
  • Self-XSS — vulnerabilities that require the attacker to trick the victim into executing code in their own browser.

5. Our commitment

We appreciate responsible disclosure and will always treat researchers with respect. However, we do not operate a formal bug bounty programme. This means:

  • We do not offer financial rewards for security reports.
  • We do not provide public acknowledgement (e.g. a credits page, social media mention, or blog post).
  • We do not maintain a hall of fame or similar recognition programme.

If this changes, we will update this page and our security.txt file.

We commit to investigating all reports made in good faith, keeping reporters reasonably informed, and not pursuing legal action against researchers who follow this policy.

6. Changes to this policy

We may update this policy as our platform evolves. Significant changes (such as introducing a bug bounty programme) will be reflected in the Expires renewal of our security.txt and the date at the top of this page.