Responsible disclosure & bug bounty policy
We want to know about any vulnerability you find in California Proxies. Here you will find what is in scope, what earns a payment, what does not, and how to report, so nobody on either side is surprised.
Scope
In scope
- This website,
californiaproxies.com - The customer dashboard you sign into and the API behind it
- Handling of rotation links, API keys and proxy credentials within the dashboard
Out of scope
- Proxy gateways and modem hosts, plus the mobile carrier networks that sit behind them
- Services run by third parties, like payment processors, Telegram, Cloudflare and email providers
- Marketing assets served from legacy CDN paths
- Customer accounts or data that belong to somebody else
What we pay
What earns a reward is demonstrated impact on our systems or our customers. Amounts are in USD.
- Remote code execution on our servers
- SQL injection that reads customer data or writes to it
- Getting into any account without its credentials by bypassing authentication
- Payment or balance tampering that gets you proxies, credit or refunds without paying
- Leaking other customers' proxy credentials or personal data in bulk
- IDOR that lets you read or change another customer's proxies, orders or account details
- Stored cross-site scripting that fires in the session of another customer or an admin
- Moving from a customer account up to admin functions through privilege escalation
- Server-side request forgery reaching internal services
- Capturing another account's session, API key or rotation link
- CSRF on an action that alters the state of an account
- Reflected XSS that needs the victim to click a link
- Rate-limit bypasses resulting in a demonstrated account takeover
- Pricing or business-logic bugs whose financial impact has been demonstrated
These get acknowledged and fixed when warranted, not paid. Check the full list below before you write up your report.
What we do not pay for
We rate these no higher than Low or Informational. We'll read them and fix what's worth it, but they earn no bounty, and calling the report Critical or High does not change that.
- A logged-in session that keeps working after you log out, reset or change the password, until its token expires
- Absent or “weak” CSP, HSTS, X-Frame-Options or Referrer-Policy headers without a working exploit
- Clickjacking against pages that have no sensitive actions on them
- Cookie flags on any cookie other than a session cookie
- Discovering which emails or usernames exist, including via timing or error messages
- Notes on forgot-password, login or rate limiting with no demonstrated account takeover
- Views on our password policy: length, complexity, common-password lists, no forced rotation
- Two-factor authentication that is missing, or 2FA left optional
- Self-XSS, or any XSS an attacker can only fire in their own session
- CSRF against login, logout, language and similar non-sensitive forms
- Open redirects with no token or credential leakage
- Leaked software versions, server banners, stack traces or paths with no sensitive data in them
- SPF, DKIM or DMARC configuration reports
- Results from automated scanners that come without a proof of concept
- Denial-of-service, resource exhaustion, brute forcing, or any test that puts load on the system
- Social engineering or phishing against our team or customers; physical attacks
- Vulnerabilities in the third parties we work with: payment processors, Telegram, Cloudflare, email providers
- Out-of-date libraries that lack a working exploit against our deployment
- Any attack that needs a man-in-the-middle position, a rooted phone or an already compromised device
- Best-practice suggestions, theoretical risks, and repeats of issues we already know about
How to report
Email [email protected] with the subject Security report. Add the affected URL, precise reproduction steps, the account you tested with, and a proof of concept. Within 5 business days we acknowledge your report, and within 10 business days we decide its severity.
Machine-readable contact details are at /.well-known/security.txt.
Send a reportPolicy last updated 2026-10-10.
Rules of engagement
- First valid report wins. No payment goes to duplicates or to reports of issues we already know about. A root cause earns one payment regardless of how many endpoints it affects.
- Prove it, then stop. Access only your own accounts and data. When a test would reveal another person's data, stop once you have the first proof and report it — no pivoting, downloading or persisting.
- Do not degrade the service. Skip load testing, automated fuzzing at volume, and any testing of proxy gateways, modem hosts or carrier networks. Those are out of scope entirely.
- Give us time. Wait until we have fixed the issue and 30 days have gone by before you publish. You'll hear from us when the fix goes live.
- Severity is ours to set. We judge the impact on our own systems and use the Bugcrowd Vulnerability Rating Taxonomy as the reference. We decide each payment amount at our discretion inside the ranges above, and pay it by PayPal or USDT.
