Security

Responsible disclosure & bug bounty policy

Tell us if you find a vulnerability in Mobile Proxy USA; we want to hear about it. The sections below cover what is in scope, what we pay for, what we do not pay for and how to report, so both sides know what to expect.

Scope

In scope

This website, mobileproxyusa.com
The customer dashboard that you sign in to and the API it has
Inside the dashboard: rotation links, API keys and how proxy credentials are handled

Out of scope

Proxy gateways and modem hosts together with the mobile carrier networks behind them
Third-party services in the form of payment processors, Telegram, Cloudflare and email providers
Marketing assets served from legacy CDN paths
Customer accounts or data that belong to others

What we pay

Rewards are tied to demonstrated impact on our systems or our customers. Amounts are in USD.

Critical

$100 – $250

Remote code execution on our servers
SQL injection resulting in reads or writes of customer data
Authentication bypass that lets you into any account without its credentials
Manipulation of a payment or balance to receive proxies, credit or refunds without paying
Bulk exposure of personal data or proxy credentials that belong to other customers

High

$50 – $100

IDOR that reads or changes another customer's proxies, orders or account details
Stored cross-site scripting, run inside the session of an admin or another customer
Moving a customer account up to admin functions through privilege escalation
Server-side request forgery reaching internal services
Theft of an API key, rotation link or session that belongs to another account

Medium

$20 – $50

Cross-site request forgery affecting an action which changes account state
Reflected cross-site scripting requiring that the victim click a link
A bypass of rate limiting that leads to a demonstrated account takeover
Demonstrated financial impact from a pricing or business-logic error

Low / Informational

These are acknowledged, fixed where warranted, not paid. Everything is in the full list below, so you can check before writing the report.

Rules of engagement

First valid report wins. Reports that duplicate others, or cover issues we already know about, are not paid. You are paid once per root cause, regardless of endpoints affected.
Prove it, then stop. Access only your own accounts and data. In case a test would expose another person's data, stop at the first proof and send your report — do not pivot, download or persist.
Do not degrade the service. Please do not load test, run automated fuzzing at volume, or test proxy gateways, modem hosts or carrier networks. Those are out of scope entirely.
Give us time. Please do not publish until the issue is fixed and 30 days have passed. You will be told when a fix is live.
Severity is ours to set. Impact is rated by us on our own systems, using the Bugcrowd Vulnerability Rating Taxonomy for reference. Our discretion sets the payment amount within the ranges above, and it is paid by PayPal or USDT.

Safe harbour. Research that follows these rules is authorised. We will not pursue legal action against you for testing in scope and in good faith, and we ask the same good faith from you toward us: no extortion, no threats of disclosure, no “pay first, details later”.

What we do not pay for

Such reports are accepted as no higher than Low or Informational. Every one gets read and what is worth fixing gets fixed, but no bounty is issued and a report labeled Critical or High is no exception.

Continued session access after a password reset, password change or logout, until the session token expires
Security headers that are absent or “weak” (CSP, HSTS, X-Frame-Options, Referrer-Policy) with no working exploit attached
Clickjacking issues on pages with no sensitive action present
Attributes set on cookies, other than session cookies
Enumeration of emails or usernames, including any done through timing or error messages
Login, forgot-password or rate-limit observations without a demonstrated takeover of an account
Password policy opinions about length, complexity, common-password lists and missing forced rotation
2FA not being mandatory, or two-factor authentication not offered
Self-XSS, or XSS that works only when the attacker triggers it in their own session
Non-sensitive forms, such as login, logout or language, open to CSRF
Open redirects with no leaked token or credential
Path or stack trace disclosure, server banners and software versions, with no sensitive data
SPF, DKIM or DMARC configuration reports
Automated scanner results that have no proof of concept
Testing that generates load, including denial of service, resource exhaustion and brute force
Phishing or socially engineering our customers or staff; physical attacks too
Weaknesses in the third parties we use: payment processors, Telegram, Cloudflare, email providers
Stale library versions without a working exploit against our deployment
Attacks where the attacker first needs a compromised device, a rooted phone or a man-in-the-middle position
Advice on best practice, theoretical risks and duplicates of issues already on record

How to report

Email [email protected] with the subject Security report. Include a proof of concept, the account you used, exact steps to reproduce and the affected URL. You can expect us to acknowledge within 5 business days and to decide severity within 10 business days.

Machine-readable contact details are at /.well-known/security.txt.

Send a report

Policy last updated 2026-10-10.