Skip to main content
Security

Vulnerability disclosure policy

OCCS welcomes good-faith security research. This page tells you how to reach us, what is in scope, what we ask in return, and the safe-harbor terms under which you can test.

Last updated: June 6, 2026

How to report

Email security@1clickcampaign.com with a clear technical write-up: affected URL or endpoint, reproduction steps, the impact you believe the issue has, and any proof-of-concept output (logs, screenshots, request/response captures). PGP is not yet published — if you require encrypted transport, ask in your first message and we’ll arrange a key exchange.

Machine-readable contact info is published at /.well-known/security.txt per RFC 9116.

In scope

  • www.1clickcampaign.com and 1clickcampaign.com — the production application and marketing site.
  • Public form-submission endpoints under /f/:token.
  • Authenticated user surfaces (sign in with a test account that you own).
  • API endpoints reachable from those surfaces.

Out of scope

  • Denial-of-service, volumetric load, or rate-limit testing against production.
  • Social engineering of OCCS employees, contractors, or customers.
  • Physical attacks against any office or data-center.
  • Attacks against third-party infrastructure we depend on (Stripe, Render, Cloudflare, AWS, OpenAI, Postmark, SendGrid, Twilio, etc.) — report those directly to the vendor.
  • Findings that require a rooted/jailbroken device, an outdated browser, or stolen credentials.
  • Reports generated solely by automated scanners with no demonstrated impact.
  • Best-practice opinions without a reproducible vulnerability (missing security headers on non-sensitive pages, missing HSTS preload, theoretical TLS misconfigurations on already-strong ciphers, etc.).
  • Self-XSS, tab-nabbing without exploitation path, clickjacking on pages without state-changing actions.
  • Email spoofing of domains we do not control. We enforce SPF, DKIM, and DMARC on 1clickcampaign.com; report failures of those.

Rules of engagement

  • Use only test accounts you create yourself. Do not access, modify, or exfiltrate other users’ data.
  • Stop as soon as you have proven impact. Do not pivot, escalate, or persist beyond what is necessary to demonstrate the issue.
  • Do not exfiltrate more than the minimum data needed to prove the bug. Delete any data you incidentally capture.
  • Do not publish or share the vulnerability before we have shipped a fix and given you the green light.
  • Give us a reasonable window to respond before any disclosure (we ask for at least 90 days from acknowledgement).

Our response targets

  • Initial acknowledgement: within 3 business days.
  • Triage decision (in-scope / out-of-scope / dup): within 7 business days.
  • Status updates: at least every 14 days while the issue is open.
  • Fix targets: Critical ≤ 7 days, High ≤ 30 days, Medium ≤ 90 days, Low at our discretion.
  • We will credit you in our security advisories unless you ask to remain anonymous.

Safe harbor

OCCS will not pursue civil or criminal action against researchers who, in good faith, comply with this policy. We consider research conducted under this policy to be: authorized under the Computer Fraud and Abuse Act (and similar laws in other jurisdictions); exempt from the anti-circumvention provisions of the DMCA; and exempt from restrictions in our Terms of Service that would otherwise prohibit security testing. If a third party asserts a claim against you arising from research conducted under this policy, we will make this authorization known.

This safe harbor applies only to good-faith research that stays within the scope and rules above. We retain the right to determine, in our reasonable discretion, whether a given action was conducted in good faith.

Bug bounty

We do not currently run a paid bounty program. We do offer recognition (named credit, swag where applicable) and we are tracking findings against a future public bounty — reports filed under this policy today will be considered for retroactive recognition when that program launches.

Procurement and security questionnaires can also reference our public trust & security overview and our subprocessor catalog.