Treat every free proxy as untrusted infrastructure, because it is. The operator is anonymous, the funding model is unclear, and the same socket might rotate through a botnet, a compromised home router, and a researcher's honeypot in a single week. None of that makes free proxies unusable — it makes a small set of habits non-negotiable.
The Common Attacks
The threats are not dramatic. They are the boring kind that succeed because most users do not bother to defend against them.
Credential theft on plaintext HTTP. If you log into anything over http:// through an unknown proxy, the operator sees the password. Always tunnel TLS through CONNECT or use SOCKS to a destination that itself enforces HTTPS. Modern login flows are HTTPS-only on the major sites, but legacy intranets, IoT admin pages, and old CMS deployments are not.
Header and content injection. A hostile HTTP proxy can rewrite arbitrary parts of your request: change cookies, swap referrers, inject tracking parameters, or strip cache headers. The same proxy can inject content into responses — scripts into HTML, redirects into JSON, ads into static pages. If you read server-side responses through the proxy, treat them as compromised until you can verify integrity from a trusted path.
DNS hijack via SOCKS5. SOCKS5 can resolve hostnames at the proxy. If the proxy lies about a DNS record, you connect to a server the operator controls. Set your client to resolve locally where possible: curl --resolve example.com:443:93.184.216.34, or in code, pass an IP rather than a hostname.
Traffic logging. Even a well-meaning proxy may log every URL you fetch. For threat models that include "what URLs did this person request," every public proxy is the wrong tool. Use Tor or a paid VPN with a published no-log policy and a track record of contested subpoenas.
Resource exhaustion against the client. Some proxies deliberately throttle connections to a crawl, return very large responses, or hold sockets open without sending data. Set strict response-size limits and connection timeouts on your client side.
Defences, in Priority Order
Send everything inside TLS via CONNECT or to an HTTPS destination through SOCKS. Never reuse credentials behind a public proxy that you would reuse anywhere else. Validate certificates strictly — pinning the issuer is overkill for casual use, but accepting any chain is reckless. Set short timeouts on connect and read. Log proxy responses for forensic review when the workload matters. Rotate frequently; a proxy that worked five minutes ago is not necessarily the same proxy now.
What Free Proxies Are Actually Good For
Three categories of work justify the noise. Testing geographic content variations: does your CDN serve the right page from Frankfurt versus São Paulo? Scraping public, unauthenticated data: search engine results, public APIs without rate limits per IP, content already indexed elsewhere. Verifying that your application behaves correctly when its outbound IP is unfamiliar to the target — useful for QA on systems with IP-based fraud heuristics.
Use them for that. Accept the failure rate. Do not put anything you would mind losing behind one.