Responsible disclosure & bug bounty policy
If you spot a vulnerability in BetterProxies, we want you to tell us. This page spells out scope, what we pay for, what we don't, and how to report, so nobody gets surprised.
Scope
In scope
- This website,
betterproxies.com - The customer dashboard you log into, plus its API
- Rotation links, API keys and proxy credentials as handled in the dashboard
Out of scope
- Proxy gateways, modem hosts and any mobile carrier network behind them
- Other companies' services: payment processors, Telegram, Cloudflare, email providers
- Marketing assets served from legacy CDN paths
- Customer accounts or data other than your own
What we pay
We pay for impact you demonstrate on our systems or our customers. Amounts are in USD.
- Remote code execution on our servers
- SQL injection that can read or change customer data
- Logging in to any account without its credentials via an auth bypass
- Gaming payments or balances — proxies, credit or refunds without paying
- Bulk leaks of other customers' proxy credentials or personal data
- IDOR: reading or editing another customer's proxies, orders or account details
- Stored XSS that hits another customer's or an admin's session
- Privilege escalation that takes a customer account to admin functions
- Server-side request forgery reaching internal services
- Swiping another account's API key, rotation link or session
- CSRF against an action that changes account state
- Reflected XSS that won't work unless the victim clicks a link
- Getting around a rate limit and showing it ends in account takeover
- Pricing or business-logic flaws that demonstrably cost money
Not paid, though we acknowledge them and fix them where warranted. Full list below, so check it before you write the report.
What we do not pay for
Low or Informational is the most these will ever be accepted as. We read them and fix what's worth fixing, but there's no bounty, and labeling the report Critical or High won't change that.
- Logout, a password change or a password reset not killing a session that then lives until its token expires
- Missing or “weak” CSP, HSTS, X-Frame-Options and Referrer-Policy headers unless there is a working exploit
- Clickjacking of pages with nothing sensitive to click
- Cookie attribute findings on non-session cookies
- Email/username enumeration, timing and error-message tricks included
- Forgot-password, login or rate-limit observations that stop short of a demonstrated account takeover
- Opinions about password rules: length, complexity, common-password lists, no forced rotation
- No 2FA at all, or two-factor authentication not being mandatory
- Self-XSS, or XSS that nobody but the attacker can trigger in their own session
- CSRF on non-sensitive forms such as login, logout or language
- Open redirects that don't expose a token or credential
- Version numbers, server banners, stack traces or paths shown without any sensitive data
- SPF, DKIM or DMARC configuration reports
- Automated scanner dumps without a proof of concept
- DoS, resource exhaustion, brute force or any other test that generates load
- Phishing or social engineering of our staff or customers; any physical attack
- Bugs in third parties we use (payment processors, Telegram, Cloudflare, email providers)
- Outdated libraries, unless there's a working exploit against our deployment
- Attacks needing a compromised device, a rooted phone or a man-in-the-middle spot
- Best-practice advice, theory-only risks and duplicates of known issues
Rules of engagement
- First valid report wins. Duplicates and issues we already know about don't get paid. One root cause, one payment, whatever the endpoint count.
- Prove it, then stop. Access only your own accounts and data. If a test is about to expose someone else's data, stop at the first proof and report — no pivoting, no downloading, no persisting.
- Do not degrade the service. That means no load tests, no bulk automated fuzzing and no testing of proxy gateways, modem hosts or carrier networks. Those are out of scope entirely.
- Give us time. Don't publish until we've fixed it and 30 days have passed. When the fix is live, you'll hear it from us.
- Severity is ours to set. We score impact on our own systems, with the Bugcrowd Vulnerability Rating Taxonomy as the yardstick. We pick the amount within the ranges above at our discretion and pay by PayPal or USDT.
How to report
Email support@betterproxies.com with the subject Security report. Send the affected URL, exact repro steps, the account you used and a proof of concept. Acknowledgment comes within 5 business days, and a severity decision within 10 business days.
Machine-readable contact details are at /.well-known/security.txt.
Send a reportPolicy last updated 2026-10-17.
