APIs are now at the heart of modern applications, powering authentication, data exchange, and service integration across nearly every digital ecosystem. However, this growth has also introduced new and complex attack surfaces.
According to Infosecurity Magazine (2022), API attacks have become the leading attack vector for enterprise web applications. The real-world consequences are clear:
- LinkedIn (2021): 700 million user records exposed
- Facebook (2019): 533 million users affected
- Recent cases: Zoom, T-Mobile, and Optus API data breaches
Reports such as index.dev (2024) indicates that over 90% of modern applications rely on APIs, meaning any weakness in an API can expose entire systems to compromise.
API security is no longer optional, it’s a fundamental requirement for protecting data, users, and business operations.
Why we built our own
At Unitel LLC (Mongolia), during our 2024 internal risk assessment, we identified that our API monitoring capabilities were only partially implemented. This created visibility gaps across critical systems and left us unable to detect abnormal API behaviour in real time.
While several open-source and commercial monitoring tools were evaluated, they lacked key capabilities our environment required — including deeper integration, full data control, and the ability to recognize Mongolian language–specific Personally Identifiable Information (PII) formats.
We needed a system that could:
- Integrate seamlessly with our internal Security Information and Event Management (SIEM) solution and dashboards
- Provide detailed endpoint-level visibility
- Detect subtle, API-specific anomalies
- Operate entirely within our trusted environment
We evaluated build versus buy as shown in Table 1.
| Aspect | Open source tools | In-house system (our approach) |
| Customization | Limited by community plugins | Fully customized UTF-8 processing, SSL offloading, and behavioural configuration |
| Integration | Manual configuration required | Natively integrated with internal SIEM and dashboards |
| Scalability | Needs extensive tuning for enterprise use | Designed to scale with API traffic growth |
| Visibility | Generic dashboards and detection templates | Custom metrics, alert types, and endpoint mapping |
| Data governance | External data dependencies | All processing performed internally, including regex-based Mongolian PII detection |
This comparison confirmed that a custom-built API Security Monitoring System offered greater control, better performance, and stronger alignment with our internal security framework.
Unitel’s solution: System architecture overview
Our architecture collects, analyses, and visualizes API traffic across multiple network layers and can be represented as in Figure 1.
The Capture Layer mirrors live API requests for analysis, the Analyser Backend extracts metadata (method, endpoint, response size, payload), and the dashboard/SIEM correlates anomalies, visualizes trends, and triggers alerts to the Security Operations Centre (SOC).
This design provides complete visibility into how APIs are accessed, used, and potentially abused across our environment.
Core monitoring features
The system continuously scans and reports anomalies across various event types. Below are some key alert categories and examples.
1. Suspicious login activity
Detects abnormal login behaviour such as repeated failed attempts or access from unfamiliar IP ranges.
{
"type": "alert",
"ip": "10.136.34.23",
"url": "web.uni:8111/Service1.svc",
"method": "POST",
"message": "[!] Suspicious login activity detected",
"event": "suspicious_login_activity"
}2. Large response detection
Flags unusually large responses that may indicate potential data leakage.
{
"type": "alert",
"ip": "10.136.34.23",
"url": "uoffice.uni:8111/Service1.svc",
"message": "[!] Large response (320 bytes) detected",
"event": "large_response_detected"
}3. Unknown endpoint accessed
Identifies traffic targeting undocumented or deprecated API endpoints.
{
"type": "alert",
"ip": "10.136.34.23",
"message": "[!] Unknown endpoint accessed: /Service1.svc",
"event": "unknown_endpoint_accessed"
}4. Sensitive data in payload
Scans POST bodies for tokens, credentials, or PII data.
{
"type": "alert",
"ip": "10.136.34.23",
"url": "10.10.10.10:8111/Service1.svc",
"message": "[!] Sensitive data detected in /api/user",
"event": "sensitive_uri_data"
}5. Burst request rate (rate limit exceeded)
Detects brute-force or DDoS-like patterns in API traffic.
{
"type": "alert",
"ip": "10.21.64.231",
"message": "[!] Rate limit exceeded: 10 requests in 5 s",
"event": "rate_limit_exceeded"
}Example detection logic (Python prototype)
Below is a simplified prototype showing how our rule engine detects abnormal login behaviour from captured API traffic.
# === Load and Process PCAP ===
cap = pyshark.FileCapture(PCAP_FILE, display_filter='http.request')
for pkt in cap:
try:
src_ip = pkt.ip.src
http_host = pkt.http.host
http_uri = pkt.http.request_uri
http_method = pkt.http.request_method
timestamp = pkt.sniff_time
full_url = http_host + http_uri
api_calls[(src_ip, full_url)] += 1
if http_uri.lstrip('/').startswith('Service1.svc') and http_method == 'POST':
login_attempts[src_ip] += 1
if login_attempts[src_ip] > LOGIN_ATTEMPT_THRESHOLD:
alert_msg = f"[!] Suspicious login activity from {src_ip} accessing {http_uri}"
log_output.append({
'type': 'alert',
'ip': src_ip,
'url': http_host + http_uri,
'timestamp': timestamp.isoformat(),
'method': http_method,
'message': alert_msg,
'event': 'suspicious_login_activity'
})
except Exception:
continueThis approach allows real-time analysis of API flows, correlating IP behaviour and request frequency to trigger alerts with high accuracy.
Implementation and outcomes
Development began in early 2025, following a two-month design and prototyping phase. By June 2025, the system was fully deployed and integrated into our SIEM environment.
Between June and September 2025, it generated 8,334 alerts, including eight confirmed incidents that resulted in immediate security actions.
Beyond improved detection, the project enhanced collaboration between our security and development teams, creating a shared understanding of API behaviour and response priorities.
Conclusion: From visibility to assurance
APIs have become the dominant interface for digital services — and with that, the most frequently targeted.
By developing our own API Security Monitoring System, we transformed our API layer from a black box into a monitored, measurable, and manageable asset.
This project turned a risk mitigation exercise into a cornerstone of our proactive security strategy — one that continues to evolve, ensuring our APIs remain both powerful and protected.
Watch Dashzeveg present this topic during mnNOG 7 (Mongolian language).
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.