Security

Responsible disclosure & bug bounty policy

If you come across a vulnerability in Texas Proxies, we want to hear about it. This page spells out what is in scope, what we pay for, what we do not pay for, and how to report, so there are no surprises for anyone involved.

Scope

In scope

This website, texasproxies.com
The customer dashboard you sign in on, and the API for it
The rotation links, API keys and proxy credential handling found in the dashboard

Out of scope

The proxy gateways, the modem hosts and the mobile carrier networks behind them
Services of third parties: payment processors, Telegram, Cloudflare, email providers
Marketing assets served from legacy CDN paths
Other people's customer accounts or data

What we pay

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

Critical

$100 – $250

Remote code execution on our servers
SQL injection reading or writing customer data
Getting past authentication into any account without having its credentials
Payment or balance manipulation — proxies, credit or refunds that you never paid for
Exposing proxy credentials or personal data of other customers in bulk

High

$50 – $100

Looking at or changing another customer's proxies, orders or account details (IDOR)
Stored cross-site scripting that gets run in another customer's or an admin's session
Privilege escalation letting a customer account use admin functions
Server-side request forgery reaching internal services
Stealing another account's session, rotation link or API key

Medium

$20 – $50

Using cross-site request forgery to run an action that changes account state
Reflected cross-site scripting where the victim must click a link
Beating a rate limit and showing it leads to an account takeover
Mistakes in pricing or business logic with a demonstrated financial impact

Low / Informational

Fixed where warranted and acknowledged, but not paid out. Read the full list below so you can check before you write a report.

Rules of engagement

First valid report wins. Duplicates don't get paid, and neither do reports of issues we already know. Same root cause, one payment, no matter how many endpoints it affects.
Prove it, then stop. Access only your own accounts and data. If your test would expose someone else's data, stop at the first proof and report it — don't pivot, download or persist.
Do not degrade the service. Keep away from load testing, automated fuzzing at volume and tests on proxy gateways, modem hosts or carrier networks. Those are out of scope entirely.
Give us time. Publishing waits until we have fixed the issue and 30 days are behind us. We'll give you word when a fix is live.
Severity is ours to set. With the Bugcrowd Vulnerability Rating Taxonomy as the reference, we rate impact on our own systems. We pay by PayPal or USDT, in an amount we choose at our discretion within the ranges above.

Safe harbour. Research that follows these rules is authorised. There will be no legal action pursued against you for good-faith testing within scope, and we ask that you extend the same good faith in our direction: no extortion, no threats of disclosure, no “pay first, details later”.

What we do not pay for

These top out at Low or Informational when we accept them. We will read them and fix what is worth fixing, but they do not earn a bounty, and tagging the report Critical or High does not change it.

Sessions that stay good after you log out or reset or change your password, until the token expires
Headers for security (CSP, HSTS, X-Frame-Options, Referrer-Policy) that are missing or “weak”, unless a working exploit is shown
Clickjacking pages that don't have a sensitive action
Cookie attributes, when the cookie is not a session cookie
Checking which emails or usernames are registered, including via timing or error messages
Forgot-password, login or rate-limit observations unless you demonstrate an account takeover
What you think of the password policy: length, complexity, common-password lists, no forced rotation
Not having two-factor authentication, or making 2FA optional
Self-XSS, or XSS an attacker can only fire off in their own session
CSRF on forms that aren't sensitive, like login, logout or language
An open redirect that leaks no credential or token
A software version, server banner, stack trace or path that is disclosed without sensitive data
SPF, DKIM or DMARC configuration reports
Results an automated scanner produced, without a proof of concept
Any brute force, denial of service, resource exhaustion or load-generating test
Social engineering and phishing of our staff or customers, or physical attacks of any kind
Issues on third-party platforms we use: payment processors, Telegram, Cloudflare, email providers
Outdated library versions where you have no working exploit against our deployment
Attacks you can only pull off with a compromised device, a rooted phone or a man-in-the-middle position
Duplicates of issues we know about, theoretical risks and best-practice recommendations

How to report

Email [email protected] with the subject Security report. Tell us the affected URL, the exact steps to reproduce and the account you used, and include a proof of concept. We'll acknowledge it within 5 business days and give you a severity decision within 10 business days.

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

Send a report

Policy last updated 2026-10-10.