Blog
Automated API
Security Testing for Mobile Backends
Your mobile apps talk to backend APIs that handle
credentials, personal data, and payment information. Djini's HTTP
Description
Your mobile apps talk to backend APIs. Those APIs handle login credentials, personal data, payment information, and business logic. A vulnerability in any of them can mean a data breach, regulatory fines, or loss of customer trust.
The Problem: Three Surfaces, Three Setups, Never Enough Coverage
Most organizations treat mobile security as three separate problems. Testing the Android app requires one set of tools, emulators, and expertise. Testing the iOS app requires another, with different devices, different toolchains, and different skill sets. And testing the backend APIs? That’s a third effort entirely, often owned by a different team with its own scanners, its own test environments, and its own backlog.
In practice, this means:
• Android and iOS get tested in isolation. Each platform has its own security tools, its own device lab, and its own test cycles. Findings from one platform rarely inform testing on the other, even though they hit the same backend.
• API testing is manual and incomplete. Someone has to intercept traffic, catalog endpoints, figure out authentication flows, and probe each parameter by hand. A single app can have dozens of API calls, and most never get tested.
• Tools don’t talk to each other. Your DAST scanner doesn’t know what your mobile tester found. Your mobile tester doesn’t know what your API fuzzer missed. Coverage gaps hide between the seams.
• It doesn’t scale. Every new app or major release means repeating the entire process. Security teams become a bottleneck, and testing gets cut when deadlines tighten.
The result: even when the mobile client is thoroughly tested, the backend APIs it depends on often aren’t.
How Djini Closes the Backend Gap
Djini already automates security testing of the mobile client on both Android and iOS. The HTTP Traffic Audit extends that coverage to the backend APIs those apps depend on.
Here’s how the backend API audit works once your app is uploaded:
An AI agent explores your app like a human tester would, while automatically capturing and analyzing every API call it makes. Multiple analysis layers work together to find configuration issues, injection vulnerabilities, data exposure, and business logic flaws. Every finding is verified against the live target before it’s reported, reducing false positives before they reach your team.
Once individual findings are in, Djini goes one step further: it automatically correlates results across all sources (static analysis, native binary analysis, and backend traffic) to identify attack chains where multiple vulnerabilities combine into a more severe exploit than any single finding alone. A medium-severity open redirect and a medium-severity JavaScript bridge might look manageable on their own. Chained together, they become a critical data exfiltration path.
Same pipeline. Same output. Android and iOS. No separate toolchains, no manual interception, no coverage gaps.
Ready to see what your mobile apps are really exposing?
Get a guided walkthrough with your own applications.
See It in Action: Scanning a Vulnerable WebView App
To show what this looks like in practice, we built VulnWebView, a deliberately vulnerable Android app. It’s a simple company dashboard that loads its UI in a WebView backed by a REST API. Looks harmless. Under the hood, it has a real attack chain: an open redirect in the backend, a JavaScript bridge that exposes authentication tokens and user data, and no URL validation in the WebView. Chained together, an attacker can steal credentials and personal information with a single crafted link.
We uploaded the app to Djini and let the platform run.
Upload and Configuration
We uploaded the APK and provided test credentials (bob@company.com / password123) so the AI agent can log in and explore authenticated features.
Scan configuration: upload the APK, provide test credentials, and optionally set a domain whitelist.
Note: You can also manually override the automated domain whitelist during scan configuration. This is useful when you have a known and very strict scope for API testing — for example, limiting the audit to only your production API domain. The whitelist supports exact domains (api.example.com), subdomain wildcards (*.example.com), and IP prefixes (10.*). If left empty, Djini’s AI will auto-detect in-scope domains from captured traffic.
AI-Driven Exploration
Before exploration begins, Djini automatically bypasses common security controls that would otherwise block testing: root/jailbreak detection and SSL certificate pinning. This ensures the AI agent can interact with the app and capture all traffic, even for apps that actively resist inspection.
The AI agent then launched the app and started exploring: navigating the home screen, tapping into Profile, Search, Notifications, and Settings. It filled in search fields, followed links, and triggered the notification redirect flow, generating real API traffic across every endpoint the app exposes.
The AI agent autonomously explores every screen, fills forms, and triggers API calls.
What the Backend Audit Found
The static analysis of the mobile client already identified two issues: a deep link handler that loads arbitrary URLs into the WebView, and a JavaScript bridge that exposes the session token to any page loaded in that WebView. Both are real vulnerabilities, but on their own they require an attacker to somehow get a malicious page loaded inside the app.
The HTTP Traffic Audit found the missing piece. By capturing and analyzing the actual API traffic between the app and its backend, Djini discovered an open redirect in the notification handler:
INFRA-579: Unvalidated next parameter causes open redirect — discovered through backend traffic analysis.
Unvalidated next parameter causes open redirect. The backend’s /notifications/open endpoint accepts a next query parameter and reflects it directly in the HTTP 302 Location header without validation. The AI agent navigated into the notification detail page, tapped “View attachment,” and the resulting 302 redirect was captured by the proxy. The analysis engine flagged the unvalidated parameter with full request/response evidence.
This is the kind of finding that only surfaces when you test the backend traffic. Static analysis of the mobile client can’t see it because the redirect logic lives on the server. Manual API testing might miss it because it’s buried two levels deep in the notification flow. But the AI agent explored the app thoroughly enough to trigger it, and the traffic analysis caught it.
For reference, here are the two client-side findings that the static analysis identified:
SAST-1395: Arbitrary URL Loading via Deep Link — the entry point that loads attacker-controlled URLs into the WebView.
SAST-1402: Session Token Exposure via JavaScript Bridge — the bridge that leaks the auth token to any page in the WebView.
Ready to see what your mobile apps are really exposing?
Get a guided walkthrough with your own applications.
From Separate Findings to a Critical Attack Chain
A deep link handler rated High. An open redirect found in backend traffic. A JavaScript bridge rated Medium. Individually, none of these would top a security backlog. But Djini doesn’t stop at individual findings. It automatically correlates results across static analysis and backend traffic to identify how they connect:
Djini automatically chains three findings into a Critical account takeover path (CVSS 8.8).
Critical — Account Takeover via Deep Link, Open Redirect, and JS Bridge
The open redirect is the bridge that turns two client-side issues into a full exploit:
1. Attacker crafts a vulnwebview:// deep link containing the backend’s open redirect URL
2. Backend processes the request and issues an HTTP 302 redirect to an attacker-controlled domain
3. Malicious JavaScript on the attacker domain calls AppBridge.getAuthToken() to extract and exfiltrate the session token, enabling full account takeover
Without the backend audit, the deep link and JavaScript bridge findings would remain isolated. The open redirect is what connects them into an exploitable path. Three separate findings, two different analysis layers, one exploit chain. This is exactly the kind of vulnerability that falls between the cracks when mobile client testing and API testing are done separately.
The Cost of Doing It the Old Way
A single manual penetration test for a mobile and API ecosystem typically runs between €3,000 and €7,500, and that covers just one platform, one point in time. If you’re testing Android, iOS, and backend APIs separately, you’re looking at multiple engagements per release cycle. For web applications with complex attack surfaces, costs reach €20,000+ per assessment.
Most organizations test once a year at best. But with regulations like NIS2 and DORA pushing security testing from an annual exercise to a continuous process, those costs multiply fast. And when a vulnerability slips through anyway, the stakes are severe. IBM’s 2024 Cost of a Data Breach report puts the average breach at $4.88 million.
Djini changes the economics entirely:
Cut testing costs by an order of magnitude. What used to require a multi-week manual engagement runs automatically in hours. Test every release, not just once a year, at a fraction of the cost of a single pentest.
Ship faster. Security testing no longer blocks your release pipeline. Findings come back in hours, not weeks. Your development teams fix issues in the same sprint they’re introduced, instead of triaging a pentest report months after the code was written.
One platform, full coverage. Android, iOS, and their shared backend APIs, tested through a single pipeline with consistent methodology and reporting. No more juggling three separate tool setups or coordinating across teams.
Zero manual effort. No test scripts to write or maintain. No proxy configuration. No manual app navigation. Upload your app and get a security report back.
Get Started
Djini’s HTTP Traffic Audit is available as part of the platform. If your mobile apps talk to backend APIs — and they all do — this is the fastest way to find out what’s exposed.
Start a free trial at djini.ai/pricing to run the platform against your own apps immediately.
For enterprise teams looking for a guided walkthrough, book a demo to see it in action with your own applications.
Ready to see what your mobile apps are really exposing?
Get a guided walkthrough with your own applications.
👍👍