VAPT for web applications and mobile apps — manual-led testing mapped to the OWASP Top 10 and the OWASP MASVS, with clear severity ratings and a retest included before closure.
Every engagement follows the same disciplined process — scoping, manual-led testing, exploitation, and a written report you can hand to a customer, auditor, or board. We just point it at a different surface.
Authenticated and unauthenticated testing of your web app and its APIs — the same surface attackers hit first.
Static and dynamic testing of your iOS/Android client plus the backend services it talks to.
Official security auditing required by RBI, SEBI, and Indian regulatory bodies for government and financial applications.
Automated tooling narrows the field; a human tester does the exploitation and writes the finding.
Every finding ties back to an OWASP category, so reports translate directly into your compliance evidence.
You see the test plan and the price before we start. No change orders mid-engagement.
Fix the findings, send us the build, and we verify and issue a closure letter — at no extra cost.
Switch surfaces below. Web is checked against the current OWASP Top 10 for that surface; mobile is verified against the OWASP MASVS, the standard built specifically for app-level security verification. Click any row to see how we validate it during an engagement.
The app fails to properly enforce who's allowed to view or change a given resource, letting authenticated users reach data or actions outside their role. The most common issue OWASP tracks — and as of 2025 it now absorbs Server-Side Request Forgery (SSRF) too.
How we test it → we manipulate IDs, tokens, and roles to try reaching other users' data, and confirm whether server-side requests can be redirected somewhere they shouldn't go.
Default accounts, verbose error pages, unnecessary features left switched on, or missing security headers — avoidable openings that jumped from #5 to #2 as apps lean more heavily on configuration to define behavior.
How we test it → we review headers, exposed admin interfaces, default credentials, and storage permissions across everything we can reach.
A broadened category covering the whole chain a build travels through — dependencies, build pipelines, distribution infrastructure — not just outdated libraries, since any link can be tampered with before code reaches production.
How we test it → we fingerprint dependencies and build tooling against known compromises and check whether your CI/CD pipeline could be hijacked.
Weak or missing encryption, poor key management, or unprotected data in transit and at rest — issues that surface as data exposure once an attacker can intercept traffic or read a database.
How we test it → we inspect TLS configuration, key storage, and how sensitive fields are encrypted at rest.
Untrusted input gets interpreted as an executable command — SQL, NoSQL, OS, or script injection — letting an attacker run their own logic inside the application.
How we test it → we fuzz every input field, parameter, and header across the app and its APIs looking for injection points.
Security gaps baked into the architecture itself — no threat modeling, missing rate limits on sensitive flows, trust assumptions that don't hold — that no amount of later bug-fixing can patch.
How we test it → we map abuse cases against your actual business logic, not just technical bugs, to find where the design assumes good faith.
Weaknesses in how the app confirms identity — exposure to credential stuffing, weak session handling, missing MFA enforcement. Renamed from "Identification and Authentication Failures" to better match its scope.
How we test it → we attempt session fixation, brute force, and credential-stuffing-style attacks against login and recovery flows.
A failure to verify that code, updates, or data haven't been tampered with before they're trusted and executed — distinct from supply-chain risk in that it's about validating integrity at the point of use.
How we test it → we check signature verification on updates/build artifacts and look for insecure deserialization paths.
Logging that exists but never triggers an alert is functionally useless mid-incident. Renamed to emphasize that an alert has to actually fire and reach someone.
How we test it → we carry out attack actions and confirm whether they generate a log entry — and whether it would actually trigger a response.
New for 2025. Covers how an app behaves when something goes wrong — error handling that leaks internals, logic that fails open instead of closed, or edge cases nobody designed for.
How we test it → we deliberately break things — malformed input, timeouts, partial failures — and check whether the app fails safely or fails open.
MASVS isn't a ranked list like the Top 10s — it's a verification standard organized into security domains, each broken into testable controls (e.g. MASVS-STORAGE-1). Most domains apply at two depths: L1 baseline security every app should meet, and L2 defense-in-depth for apps handling highly sensitive data (banking, health, government). Resilience sits apart as its own track, R, for apps that need to withstand a hands-on attacker reverse-engineering the binary.
Covers how the app stores sensitive data on the device — PII, credentials, cryptographic material, API keys — whether in its own private storage or a shared/public location, including data that leaks unintentionally through backups, logs, or caches.
How we test it → we pull the device's local storage, shared preferences, caches, and backups after using the app, and check whether anything sensitive is sitting there unprotected.
Covers whether the app uses cryptography correctly to protect sensitive data — proper algorithms and key lengths, no hardcoded keys, and key material handled through the platform's secure keystore rather than baked into the app.
How we test it → we identify every cryptographic primitive in use, check for hardcoded or weak keys, and confirm keys are generated and stored through the platform keystore (Android Keystore / iOS Secure Enclave).
Covers how the app verifies identity and enforces what an authenticated user is allowed to do — login flows, session handling, biometric unlock, and server-side authorization checks that can't be skipped from the client.
How we test it → we attempt session replay and biometric bypass, and call backend endpoints directly that should require a higher privilege level than the client enforces.
Covers how data is protected in transit between the app and its backend — correct TLS configuration, certificate validation, and resistance to interception even when the device itself is under an attacker's control.
How we test it → we intercept traffic with a proxy and attempt to bypass certificate pinning and force a downgrade to an insecure connection.
Covers how the app interacts with the OS and other apps on the device — permission requests, inter-process communication, deep links, and WebViews — so it doesn't expose more than it needs to or blindly trust input from another app.
How we test it → we probe exported components, deep links, and IPC channels to see if another app — or we — can trigger functionality or pull data the app didn't intend to expose.
Covers secure coding and build practices — no debug code or test endpoints left in production, proper error handling, and a process for keeping the app and its dependencies up to date.
How we test it → we review build configuration and binary metadata for debug flags, outdated dependencies, and verbose error handling that leaks internals.
Covers whether the app collects only the personal data it actually needs, is transparent about what it collects, and gives users meaningful control — distinct from security, since data can be perfectly secured and still over-collected.
How we test it → we trace what personal data the app collects and transmits, compare it against what's disclosed to the user, and flag anything collected without a clear need.
Covers defense-in-depth against reverse engineering and tampering — obfuscation, anti-debugging, root/jailbreak detection, and integrity checks — for apps that need to withstand a motivated, hands-on attacker. Sits apart from the other domains as its own verification track.
How we test it → we attempt to decompile, instrument, and patch the running app, and check whether tamper-detection or anti-debugging controls actually trigger.
The same lifecycle applies whether we're testing a web app or a mobile client — only the tooling and targets change.
We define exactly what's in bounds — applications, environments, accounts, IP ranges — and what's off-limits. Test windows and a signed authorization get locked in before anyone touches a target.
We map every entry point in scope — endpoints, screens, exposed services, or a model's available tools — and build abuse-case scenarios around how someone would actually try to break in.
Tooling clears the obvious ground fast. Every flagged issue then gets manually verified by a tester; nothing reaches the report just because a scanner said so. This is where most engagement time goes.
Confirmed weaknesses get exploited under controlled conditions to prove real-world impact, chained where it makes sense — always within the agreed Rules of Engagement.
Every finding gets a CVSS score, a plain-language summary for leadership, and a technical write-up — mapped explicitly to its OWASP category so it drops into your compliance evidence.
Your engineers get direct access to the tester who found each issue, not a ticket queue, so they can confirm a fix actually closes the gap before a sprint gets spent on it.
Once fixes ship, we re-run the specific tests that found each issue. You get a closure letter you can hand to a customer, partner, or auditor as evidence the findings were remediated.
Security claims mean little without a framework behind them. iCompaas VAPT structures its testing and reporting around recognized approaches to risk (OWASP Top 10 and MASVS) — so your findings are organized and explainable to auditors.
That structure turns a pile of red-team output into something your compliance team can actually use to pass SOC 2, ISO 27001, and CERT-In audits.