- Correctly detecting a VPN does not prove that its user is committing fraud.
- A VPN alone returns review under Maskbreak’s base policy; your account rules can change the final decision.
- Enforce review on your server and verify the next step before continuing the protected action.
- Measure successful customer completion as well as flagged traffic.
On this page
Maskbreak is a VPN, proxy and fake-browser detection API for signup, login and checkout. To use VPN detection without unnecessarily blocking customers, separate the network signal from your response: a VPN alone returns review under the base policy, and your application decides which verified next step is appropriate.
This guide is for SaaS developers and fraud teams whose customers use privacy tools, work networks or mobile connections. Maskbreak is free during open beta, with no credit card and a standard allowance of 1,000 visitor checks per hour. See the current allowance and terms before rollout.
Is it a detection false positive, or a policy mistake?
There are two different problems. A classification error means a connection is labelled as a VPN when it is not. A policy mistake means the connection really uses a VPN, but your app treats that fact as sufficient evidence to refuse a legitimate customer. Improving detection alone will not fix the second problem.
Review the visit’s network signals, device evidence and final decision separately. Maskbreak names a VPN or proxy service when known; an absent name is not proof that no privacy tool is present. Likewise, a risk score is not the probability that a person is a fraudster.
Account for privacy tools and shared connections
A customer may use a VPN intentionally or reach you through a company network. Safari users can also use iCloud Private Relay, which is not the same product as a general-purpose VPN. Apple explains that relay addresses can be shared and recommends adapting IP-based fraud controls to avoid affecting legitimate users.
Do not infer an individual identity from a shared exit address, and do not treat a browser brand as a trust guarantee. Your policy should consider the action being attempted: reading public documentation, signing in and changing a payout destination need not have identical requirements.
Wire it into your own app: a free key returns decision, risk_score and reasons for every visit, 1,000 requests an hour, no card.
Get an API keyUse a decision policy customers can finish
| Result | Application response |
|---|---|
allow with usable required evidence | Continue existing authentication and authorization. A fraud check does not replace either. |
review | Hold the sensitive action and offer the additional verification your policy requires. |
block | Decline the action and provide a safe support route without exposing detailed detection rules. |
| Missing evidence or unavailable evaluation | Apply your documented fallback. Never display “safe” merely because a check failed. |
These are implementation responsibilities, not automatic screens that appear after you install an SDK. Account rules and exception pins can change Maskbreak’s final recommendation. Inspect the returned decision, rather than recreating policy from one flag or a hard-coded score threshold.
Make review an actual verification flow
For a login, your existing MFA can provide a next step. For another action, choose a check that establishes what you need to know; a bot challenge is not proof of account ownership. OWASP’s authentication guidance describes risk-based reauthentication and the importance of maintaining secure session handling.
Record the pending action on your server. Verify completion on the server, bind it to the right account and action, expire it, and prevent replay. A browser flag such as verified: true must not unlock the action. Give the person a concise message, for example: “We need one more check before you continue,” followed by an actionable button and a support option.
Keep MASKBREAK_API_KEY in your backend’s secret store. Collect live browser evidence and forward it to your backend for POST /v1/evaluate; follow the integration guide for status checks, incomplete evidence and error handling. A bare-IP lookup is not a substitute for that live evaluation.
Measure friction, not just flagged visits
Track how often review is requested, how often it is completed, where customers abandon it and how many support cases overturn a refusal. Separate unavailable checks from risk-based refusals. Otherwise a provider outage can look like an improvement in blocked traffic.
Before enforcing a new policy broadly, test it on your own ordinary, VPN and privacy-relay sessions and a small approved rollout. Include a missing SDK, a failed evaluation and a failed verification attempt. The VPN testing checklist distinguishes synthetic contract tests from live detection tests.
Use narrow, reviewed exceptions where justified; do not permanently trust everyone who shares a commercial exit address. Start with a free account, confirm a real visit in the dashboard, then verify that your own backend enforces the next step.
Questions people ask
- Is a VPN detection result a false positive if the customer is legitimate?
- Not necessarily. The VPN classification can be correct while a fraud-blocking decision is wrong. Check network classification and customer outcomes separately.
- Does Maskbreak block every VPN user?
- No. A VPN alone returns review under Maskbreak’s base policy. Account rules and exception pins can change the final recommendation, and your backend must enforce the resulting decision.
- Can I use a VPN detection API without requiring a CAPTCHA?
- Yes. Maskbreak does not require a CAPTCHA to return network and device signals. Your app can use an appropriate server-verified step, such as existing MFA, for review results.
- Does an inconclusive check mean the visit is safe?
- No. Missing or unavailable evidence is not a clean result. Use a documented fallback, such as holding a sensitive action for verification, and offer a clear retry or support route.
- Can I start testing VPN detection for free?
- Maskbreak is free during open beta with no credit card and a standard allowance of 1,000 visitor checks per hour. Evaluation and authenticated IP lookup share the key’s hourly allowance.
Paste it in, then watch the verdicts
The public sk_test_sandbox key returns the documented allow, review and block shapes with no account, so the failure path is testable before you go live. SDKs for Node, Python and PHP, or plain HTTP. The <a href="/api">API reference</a> and the <a href="/pricing">free tier</a> cover the rest.