Security Policy

Last updated

CamdenHistory.com takes the security of our website and infrastructure seriously. We appreciate the efforts of security researchers and community members who help us identify and responsibly disclose potential vulnerabilities.

This policy describes how to report security issues, what we consider acceptable testing, and how we handle disclosures.


Reporting a Security Issue

If you believe you have discovered a security vulnerability, please report it responsibly.

Contact: webmaster@camdenhistory.com

Please include as much detail as possible, such as:

  • The affected URL(s)
  • A description of the vulnerability
  • Steps to reproduce
  • Any relevant screenshots or logs

We aim to acknowledge reports within 7 business days.


Supported Systems

This policy applies to the following domains and services:

  • https://camdenhistory.com
  • https://dvrbs.camdenhistory.com
  • https://*.camdenhistory.com

Third-party services, embedded content, analytics platforms, and external integrations are out of scope unless explicitly hosted under the domains listed above.


Responsible Disclosure Guidelines

We ask that you:

  • Allow reasonable time for us to investigate and remediate the issue before public disclosure
  • Avoid accessing, modifying, or deleting data that does not belong to you
  • Avoid actions that could degrade service availability or impact users
  • Use the minimum level of testing required to demonstrate the issue

We do not operate a public bug bounty program at this time, but we do appreciate responsible reports.


Out of Scope / Not Accepted

The following activities are not authorized and should not be reported:

  • Denial-of-service (DoS / DDoS) testing
  • Automated vulnerability scanning or brute-force attacks
  • Physical security testing
  • Social engineering, phishing, or staff impersonation
  • Issues that require user-installed malware or compromised client devices
  • Vulnerabilities solely affecting third-party services

Common Non-Issues

The following are generally not considered security vulnerabilities:

  • Missing or informational HTTP security headers where mitigations are already in place
  • Self-XSS
  • Clickjacking on pages without authenticated state
  • Rate-limiting concerns on non-authenticated, read-only endpoints
  • Issues requiring unrealistic user interaction or outdated browsers

Safe Harbor

If you act in good faith and in accordance with this policy, we will not pursue legal action against you for your security research. We consider such research to be authorized under this policy.


Changes to This Policy

This policy may be updated from time to time. The latest version is always available on this page.