Security

Responsible disclosure & bug bounty policy

If you find a security problem in American Mobile Proxies, we want you to tell us. Read this page to learn the scope, what we pay for, what we do not pay for, and how to send a report, so you and we have no surprises.

Scope

In scope

This website, americanmobileproxies.com
The customer dashboard where you log in, and the dashboard's API
How the dashboard treats rotation links, API keys and proxy credentials

Out of scope

Proxy gateways, modem host computers and the mobile carrier networks behind them
Services from outside companies, like payment processors, Telegram, Cloudflare and email providers
Marketing assets served from legacy CDN paths
Customer accounts or data of other people

What we pay

We give rewards when you show impact on our systems or on our customers. Amounts are in USD.

Critical

$100 – $250

Remote code execution on our servers
SQL injection that can read or write the data of customers
Going around authentication to open any account without its credentials
Changing payments or balances to get proxies, credit or refunds without paying
Exposure of the proxy credentials or personal data of many other customers at once

High

$50 – $100

Using IDOR to read or change the proxies, orders or account details of another customer
Stored cross-site scripting (XSS) that runs in the session of an admin or another customer
Using a customer account to get admin functions by escalating privileges
Server-side request forgery reaching internal services
Getting another account's API key, rotation link or session by stealing it

Medium

$20 – $50

Cross-site request forgery (CSRF) on an action that changes the account
Reflected cross-site scripting (XSS) where the victim must click a link
Going around a rate limit in a way that is shown to lead to account takeover
Errors in prices or business logic that show a financial impact

Low / Informational

We acknowledge them and fix them if warranted, but do not pay. Please read the full list below before you write the report.

What we do not pay for

We accept these only as Low or Informational, not higher. We will read them and fix what needs fixing, but we give no bounty, even if the report says Critical or High.

After logout, password change or password reset, the old session still works until the session token expires
Security headers (CSP, HSTS, X-Frame-Options, Referrer-Policy) not present or “weak”, when there is no working exploit
Clickjacking on a page where there is no sensitive action
Cookie attributes on cookies not used for the session
Finding out which email or username exists, also by timing or by error messages
Things noticed on forgot-password, login or rate limits, without showing an account takeover
What you think about our password rules: length, complexity, common-password lists, no forced rotation
There is no two-factor authentication, or 2FA is not required
Self-XSS, or XSS that only the attacker can start in their own session
CSRF on forms that are not sensitive, like login, logout or language choice
Open redirects where no token or credential is leaked
A visible software version, server banner, stack trace or file path that has no sensitive data
SPF, DKIM or DMARC configuration reports
Results from automatic scanner tools without a proof of concept
Denial of service, using up resources, brute force, or any test that makes load on our systems
Phishing or social engineering of our workers or customers, or physical attacks
Problems in other companies we use: payment processors, Telegram, Cloudflare, email providers
Old versions of libraries, when there is no working exploit against our deployment
Attacks that need the attacker to have a man-in-the-middle position, a rooted phone or a compromised device
Best-practice advice, risks only in theory, and repeats of known issues

Rules of engagement

First valid report wins. We do not pay for a duplicate report or for an issue we know about already. We pay one time for one root cause, even if many endpoints have the problem.
Prove it, then stop. Access only your own accounts and data. If your test would show data of another person, stop at the first proof and report it — do not pivot, download or persist.
Do not degrade the service. Do not do load tests, do not run automated fuzzing in large volume, and do not test proxy gateways, modem hosts or carrier networks. Those are out of scope entirely.
Give us time. You may publish only when we have fixed the issue and 30 days have passed. We will tell you when the fix is online.
Severity is ours to set. We decide the impact on our own systems, and we use the Bugcrowd Vulnerability Rating Taxonomy as the reference. We decide how much to pay, at our discretion, within the ranges above, and we pay by PayPal or USDT.

Safe harbour. Research that follows these rules is authorised. We will not start legal action against you for good-faith testing in scope, and we ask you to act in good faith with us too: no extortion, no threats of disclosure, no “pay first, details later”.

How to report

Email [email protected] with the subject Security report. Please write the affected URL, the exact steps to repeat the problem, the account you used, and a proof of concept. We answer within 5 business days to say we received it, and we decide the severity within 10 business days.

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

Send a report

Policy last updated 2026-10-10.