How I Bypassed Country Restrictions in 5 Minutes: A Bug Hunter’s Guide to Server-Side Validation Flaws + Video

Listen to this Post

Featured Image

Introduction:

Client-side restrictions—such as dropdown menus that limit country codes—are easily bypassed because they exist only in the browser. Attackers can intercept and modify API requests to test whether the server actually validates the data; when the server blindly trusts the client, vulnerabilities like country restriction bypass emerge, allowing unauthorized phone numbers to receive OTPs or access restricted features.

Learning Objectives:

  • Understand how to identify and exploit weak server-side validation by tampering with request parameters.
  • Learn to use interception tools (Burp Suite, OWASP ZAP) and command-line utilities to modify country codes in API calls.
  • Implement secure coding practices—allowlists, backend checks, and input normalization—to prevent restriction bypass attacks.

You Should Know

1. Understanding the Country Restriction Bypass Vulnerability

This vulnerability occurs when an application restricts certain country codes (e.g., India’s +91) only in the user interface, but the backend API does not re-validate the country code parameter. In Suraj Gupta’s finding, the phone number field lacked an Indian option, but by selecting Canada (+1), intercepting the request, and changing `country_code=+1` to country_code=+91, the OTP was successfully delivered to an Indian number.

Step‑by‑step guide to replicate (ethical testing only):

  1. Navigate to the target application’s phone number input form.
  2. Open your browser’s developer tools (F12) → Network tab.
  3. Select any allowed country from the UI and enter a test phone number.
  4. Before submitting, enable Burp Suite (or OWASP ZAP) proxy (default 127.0.0.1:8080).
  5. Submit the form and intercept the request in the proxy.
  6. Locate the parameter controlling the country code (e.g., country, cc, phone_country).
  7. Change its value to a restricted code (e.g., `+91` for India, `+86` for China).

8. Forward the modified request.

  1. If you receive an OTP or success message, the server lacks proper validation.

Linux / Windows command alternative using `curl`:

 Original request (e.g., Canada)
curl -X POST https://target.com/api/send-otp \
-H "Content-Type: application/json" \
-d '{"country_code":"+1","phone":"1234567890"}'

Modified request (India)
curl -X POST https://target.com/api/send-otp \
-H "Content-Type: application/json" \
-d '{"country_code":"+91","phone":"9876543210"}'

On Windows PowerShell:

Invoke-RestMethod -Uri "https://target.com/api/send-otp" -Method Post -Body '{"country_code":"+91","phone":"9876543210"}' -ContentType "application/json"
  1. Intercepting and Modifying Requests with Burp Suite (Detailed Setup)

Burp Suite is the industry standard for web application testing. Follow these steps to intercept and tamper with country code parameters.

Step‑by‑step:

1. Download and launch Burp Suite Community Edition.

  1. Go to Proxy → Options → add a proxy listener on `127.0.0.1:8080` (default).
  2. Configure your browser to use this proxy (e.g., Firefox → Settings → Network Settings → Manual proxy → HTTP proxy 127.0.0.1, port 8080).
  3. Install Burp’s CA certificate (visit `http://burp` in the proxied browser) to intercept HTTPS traffic.

5. In Burp, ensure Intercept is on.

  1. Perform the action on the target website (e.g., submit phone number).
  2. In the intercepted request, modify the `country_code` or similar parameter.
  3. Click Forward to send the tampered request to the server.
  4. Observe the response—if the server processes the restricted code, you’ve found a bypass.

Pro tip: Use Burp’s Intruder to automate testing of multiple restricted country codes. Send the request to Intruder, set payload position on the country code, load a list of country codes (e.g., +91, +86, +98, +20), and analyze response lengths or status codes.

  1. Server-Side Validation: How to Fix It (Code Examples)

The root cause is trusting client‑supplied data. Fixes must be implemented entirely on the backend. Below are secure coding examples.

Python (Flask) – Allowlist approach:

ALLOWED_COUNTRY_CODES = ['+1', '+44', '+61']  Canada, UK, Australia

@app.route('/api/send-otp', methods=['POST'])
def send_otp():
data = request.get_json()
country_code = data.get('country_code')
phone = data.get('phone')

if country_code not in ALLOWED_COUNTRY_CODES:
return jsonify({"error": "Country code not allowed"}), 400

Normalize input: remove spaces, dashes, leading zeros
phone = re.sub(r'\D', '', phone)
if not phone.isdigit() or len(phone) < 5:
return jsonify({"error": "Invalid phone number"}), 400

Proceed to send OTP
return jsonify({"success": True}), 200

Node.js (Express) – Using regex validation:

const allowedCodes = ['+1', '+44', '+61'];
app.post('/api/send-otp', (req, res) => {
const { country_code, phone } = req.body;
if (!allowedCodes.includes(country_code)) {
return res.status(400).json({ error: 'Country code not permitted' });
}
if (!/^[0-9]{7,15}$/.test(phone)) {
return res.status(400).json({ error: 'Invalid phone format' });
}
// Send OTP logic
res.json({ success: true });
});

Key takeaway: Never rely on front‑end dropdowns or JavaScript checks. The server must independently validate every parameter.

4. API Security Hardening: Beyond Country Codes

The same bypass technique applies to other hidden parameters: region locks, user roles, discount codes, or trial periods. Implement these mitigations:

Step‑by‑step hardening guide:

  1. Input Allowlist: Define acceptable values on the server (e.g., list of supported country codes). Reject anything else.
  2. Parameter Binding: Use strict data types. A country code should be a string with a predefined regex: ^\+\d{1,4}$.
  3. Rate Limiting: Prevent brute‑forcing of restricted codes by limiting requests per IP or session. Example using `iptables` or application‑level middleware.
  4. Logging & Monitoring: Log all failed validation attempts. Suspicious patterns (e.g., rapid switching of country codes) should trigger alerts.
  5. Cloud Hardening (AWS WAF): Create a rule to inspect `country_code` in API requests and block those not in an allowlist.

Linux command to monitor logs in real‑time:

tail -f /var/log/nginx/access.log | grep "country_code"

Windows (PowerShell) equivalent:

Get-Content C:\inetpub\logs\LogFiles\W3SVC1\u_ex.log -Wait | Select-String "country_code"
  1. Automating Bypass Testing with OWASP ZAP and Python

For bug hunters, automation speeds up discovery. Use OWASP ZAP’s Fuzzer or write a Python script to replace country codes.

Python script using `requests`:

import requests

target_url = "https://target.com/api/send-otp"
restricted_codes = ['+91', '+86', '+98', '+20', '+55']
headers = {"Content-Type": "application/json"}

for code in restricted_codes:
payload = {"country_code": code, "phone": "1234567890"}
response = requests.post(target_url, json=payload, headers=headers)
if response.status_code == 200 and "OTP" in response.text:
print(f"[!] Bypass successful with {code}")
else:
print(f"[-] {code} blocked")

OWASP ZAP Fuzzing steps:

1. Capture the request in ZAP.

2. Right‑click the country code parameter → Fuzz.

  1. Add a payload file containing restricted country codes (one per line).
  2. Start fuzzing; ZAP will show which payloads return a success (200) vs error (400/403).

  3. Mitigation Deep Dive: Why Client‑Side Restrictions Are Never Enough

Many developers assume that disabling an option in the UI prevents users from selecting it. This is false. Attackers can:
– Edit HTML/JavaScript in real‑time using browser dev tools.
– Directly call the API via `curl` or Postman, bypassing the UI entirely.
– Use parameter pollution or encoding tricks (e.g., URL‑encode `+` as %2B).

Step‑by‑step example of disabling the UI restriction:

1. Right‑click the country dropdown → Inspect.

  1. Find the `` (often present but hidden with display:none).
  2. Delete the `disabled` or `hidden` attribute, or set display:block.
  3. Select India and submit. If the server accepts it, you’ve found the same vulnerability without even intercepting traffic.

Permanent fix: The server must treat all client input as untrusted. Implement a backend allowlist that is enforced regardless of what the UI sends.

What Undercode Say

  • Key Takeaway 1: Client‑side restrictions are mere suggestions—never trust them. Always verify every parameter on the server, especially country codes, roles, and pricing identifiers.
  • Key Takeaway 2: This vulnerability is widespread because developers prioritize UI polish over backend validation. A single modified request can turn a “not allowed” into “OTP delivered,” leading to account takeover, SMS bombing, or geo‑restriction bypass.

Analysis (10 lines):

The country restriction bypass is a textbook example of broken access control (CWE‑602). It often goes undetected because testers focus on the visible UI. However, its impact can be severe: an attacker in India could sign up for a Canada‑only service, receive OTPs, and bypass KYC checks. Fixing it requires shifting left—educating developers to never rely on front‑end filtering. Automated scanning tools miss this because they follow the UI flow; manual testing and parameter tampering are essential. Bug bounty platforms frequently pay $500–$5000 for such findings, especially on fintech and e‑commerce sites. The root cause is not technical complexity but a failure of secure design principles. As APIs become more prevalent, this class of vulnerability will only grow unless organizations adopt “zero trust” for client inputs.

Prediction

As more applications adopt API‑first architectures and serverless functions, the attack surface for parameter tampering will expand dramatically. AI‑driven API security gateways will soon be able to detect anomalous country code changes by learning normal user behavior (e.g., a user in Lebanon suddenly sending requests with +91). However, until then, manual bug hunters will continue to exploit this flaw. In the next two years, regulators may mandate server‑side validation for phone number fields in financial services, driving adoption of backend allowlists. The most forward‑thinking security teams will implement deterministic validation—where the client’s geolocation (via IP) is cross‑checked against the submitted country code, blocking any mismatch automatically. Failure to adopt these measures will result in more data breaches and SMS‑based account takeovers.

▶️ Related Video (76% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Surajgupta2387 Bug – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky