AppSecAugust 15, 202640 min read

Web Application Penetration Testing: Complete Guide for Indian SaaS Founders (2026)

Q: What is the difference between VAPT and WAPT?

VAPT is a broader term — Vulnerability Assessment and Penetration Testing — often used in Indian regulatory contexts (RBI, SEBI, IRDAI) to describe the combined offering. WAPT is specifically the web-application scope within that broader offering. A VAPT engagement may include WAPT, network pen testing, cloud configuration review, and mobile pen testing depending on scope. When a regulator or enterprise buyer asks for a VAPT report, they typically expect coverage across whatever attack surfaces the target actually has.

Q: We're pre-launch — should we still test?

For pre-launch systems, a combined threat-modeling plus design-review engagement is often more cost-effective than a full WAPT. Architecture, authentication design, tenant isolation model, and API-surface design are reviewed before implementation, catching problems when they are cheap to fix. Full WAPT once the system is production-shaped.

Q: Can WAPT be scoped alongside AI red-teaming or a network pen test?

Yes, and often should be. WAPT plus AI red-team (if the product has AI surface) plus network pen test of the deployment infrastructure covers the full stack. Scoped together, findings can be reconciled into one integrated report with a single executive summary — reducing the reporting overhead the client's leadership has to consume.

OWASP Top 10 + API Top 10 + ASVS v5, six-phase methodology, INR cost brackets, DPDP Act + HIPAA overlays — WAPT for Indian SaaS founders in 2026.

By TheZyberSecurity

TL;DR — Web application penetration testing (WAPT) is offensive security applied to a running web application — its browser-side code, its APIs, its authentication and session machinery, its business logic, its backend, and every third-party integration it depends on. It is anchored on the OWASP Top 10 (2021), OWASP Application Security Verification Standard (ASVS) v5.0, OWASP API Security Top 10 (2023), OWASP Web Security Testing Guide (WSTG), PTES, and NIST SP 800-115, with every finding tagged against CWE identifiers and scored with CVSS 3.1. It is not a vulnerability scan. It is not a bug bounty. It is a scoped, adversary-emulating engagement operated by humans (with automation support) that answers a single question: given the way this application is deployed, authenticated, integrated, and used — what damage can an attacker cause? This guide walks through the scope, the frameworks, the attack surface of a modern web application, the OWASP Top 10 (2021) and OWASP API Security Top 10 (2023) risk classes, the six-phase testing methodology, the difference between black-box, gray-box, and white-box engagements, the deliverables to expect, cost brackets in INR, and how the whole thing maps to India-specific compliance (DPDP Act 2023, HIPAA for cross-border healthtech, MITRE ATT&CK for context). Written for founders and heads-of-engineering at Indian SaaS companies who need to answer "what does a WAPT actually cover?" before scoping one.

What is web application penetration testing?#

Web application penetration testing is the discipline of attacking a web application — with permission, under scope, with reproducible evidence — to find how an adversary would abuse it. The output is not an opinion. It is a set of proven exploitation paths, each with a captured request/response, each mapped to a CWE and a CVSS 3.1 vector, each accompanied by remediation guidance and a re-test after the client fixes it.

A useful working definition: WAPT is offensive security applied to the full path from an unauthenticated internet user to the sensitive data and state changes that the application is supposed to protect. That path traverses the front-end, the API layer, the authentication and session subsystems, the business logic, the backend data stores, and any third-party services woven into the flow. Each hop is an attack surface. A findings report that only covers the login page and misses the tenant-boundary check on /api/v2/reports/{id} is not a WAPT — it is a login-form review.

The term is used interchangeably with web app pen testing, web application security assessment, application security testing, and sometimes loosely with VAPT (vulnerability assessment + penetration testing). The nuance that matters: a penetration test is human-led adversary emulation with proven impact; a vulnerability assessment is broad automated scanning with unproven findings. Both have their place. They are not the same deliverable, and no serious buyer should accept a scanner report as a WAPT.

WAPT vs vulnerability scanning vs bug bounty — when each fits#

Three offerings frequently confused. Each answers a different question.

Vulnerability scanning. Automated tooling (Nessus, Burp Scanner, OWASP ZAP, Acunetix, Qualys) crawls the application and matches responses against signatures for known issues. Coverage is broad. Findings are shallow. False positives are common. Depth is limited to what a scanner can detect without understanding the application's business logic. Good for continuous, low-cost baseline hygiene. Bad for anything requiring exploitation proof, chain construction, or logic-layer analysis. Typical cost in India: ₹15-40k per scan-cycle.

Web application penetration testing (WAPT). Human operators augment scanner output with manual testing, chain-building, business-logic analysis, and adversary emulation. Findings are validated end-to-end with reproduction steps and impact demonstration. Coverage is scoped rather than exhaustive — testers focus on the surfaces most likely to yield exploitable findings. Typical cost in India: ₹75k-3L per engagement, depending on scope.

Bug bounty. Crowd-sourced testing. Independent researchers probe a production application under a public or private program (HackerOne, Bugcrowd, Intigriti) and get paid per validated finding. Coverage is unpredictable — depends on which researchers show interest. Best used after a WAPT-quality baseline exists, to catch the residual issues that a scoped engagement did not cover. Typical cost in India: ₹0 program setup + variable per-finding payouts (₹5k-5L per finding).

The three complement each other. Continuous scanning catches low-hanging misconfigurations between engagements. Periodic WAPT gives you defensible evidence for enterprise procurement and regulatory conversations. A bug bounty program creates persistent adversary pressure on production. A serious 2026 Indian SaaS security posture uses all three, sequenced correctly: WAPT first (establish baseline), scanner second (maintain hygiene), bug bounty third (add persistent pressure). Skipping WAPT and going straight to bug bounty is the most common expensive mistake — bounty hunters will find things, but you will have no framework-mapped evidence to hand a compliance auditor.

Why WAPT matters for Indian SaaS in 2026#

Three forces made WAPT a first-class business concern for Indian SaaS founders rather than a check-box exercise.

Enterprise procurement gates hardened. Indian SaaS selling to global enterprise buyers — banking, insurance, healthcare, US Fortune 1000 — now routinely receives vendor-security questionnaires asking for a recent WAPT report (within 12 months), the scope statement, the findings summary, and remediation status. Without a report, the vendor either fabricates one (career-ending when discovered), scrambles to arrange one under procurement time pressure (typically 3-6x the normal cost), or loses the deal. Founders who ran a WAPT proactively at Series A have this file ready when the Series B customer asks in month one of the pilot.

DPDP Act 2023 in force. India's Digital Personal Data Protection Act 2023 is in force, with MeitY-issued subordinate rules progressively defining Data Fiduciary and Data Processor duties. Any web application processing personal data of Data Principals located in India — nearly every consumer-facing and B2B SaaS product — is in scope. Section 8 (Data Breach Notification) makes a breach involving personal data a regulator-reportable event. WAPT findings identifying routes to unauthorized personal-data disclosure become pre-breach remediation opportunities. Ignoring them, then getting breached through the exact route the WAPT report flagged, is negligence on the record.

Regulators + sector supervisors ask. RBI (Reserve Bank of India) directives for regulated entities require periodic VAPT. SEBI (Securities and Exchange Board of India) cyber-security framework for market intermediaries requires the same. IRDAI (Insurance Regulatory and Development Authority of India) applies similar expectations. CERT-In (Indian Computer Emergency Response Team) empanelment status is a differentiator for firms serving these regulated buyers. HIPAA (for Indian healthtech serving US patients) requires technical safeguards evaluation that WAPT partially satisfies. The regulatory perimeter around web-application security has grown consistently through 2024-2026, not shrunk.

Add the operational reality: original studies of Indian breach patterns show the modal 2025-2026 breach traces to (a) a broken-access-control finding on an authenticated API endpoint, (b) an authentication weakness enabling account takeover, or (c) an SSRF finding in a file-upload feature that pivoted into cloud-metadata credential theft. All three are findings a competent WAPT would surface pre-breach. The report is cheaper than the incident.

Who needs WAPT?#

Not every organization needs a full engagement today. Exposure scales with a small number of factors — evaluate each honestly.

Production users touching real data. If your application is in production with real users touching real data (not a demo, not a prototype), you are past the "should we test?" threshold.
Personal data, financial data, or health data. If your application processes PII, PHI, financial records, source code, trade secrets, or any category covered by DPDP Act 2023 as personal data — a successful exploitation becomes a data-breach event with regulatory notification obligations.
B2B selling to enterprise. If your customers require security assessments as part of vendor due diligence — a WAPT report is often the fastest way to unblock a stalled procurement conversation. Ask any Indian SaaS founder who has closed a US Fortune 500 deal.
Multi-tenant architecture. If your application serves multiple tenants from shared infrastructure, cross-tenant data leakage becomes a class of finding that only human-led testing reliably surfaces.
Payments, wallets, transfers. If your application handles money flows — payment gateways, wallet balances, transfer initiation — the exploit-to-impact translation is direct and expensive.
APIs consumed by third parties. If external developers or partners consume your APIs, the API surface is a distinct engagement scope with distinct classes of finding.
Regulatory footprint. If you serve customers in India (DPDP Act), US healthcare (HIPAA), EU (GDPR + NIS2), or any regulated Indian sector (RBI / SEBI / IRDAI) — expect WAPT evidence to become a mandatory check-box item.

The clearest candidate profile in the Indian market as of 2026: a B2B SaaS company, Seed to Series B, 10-200 employees, with a multi-tenant production application handling any category of sensitive customer data, selling into regulated-industry or enterprise buyers. That segment often under-invests in WAPT until an enterprise procurement conversation forces the issue, then over-pays for an emergency engagement compressed into two weeks. Proactive scheduling — one WAPT per year, plus one on any major architecture change — is meaningfully cheaper.

Framework foundations: what a WAPT maps to#

Every finding in a rigorous WAPT should map to at least one recognized framework. Six matter most.

OWASP Top 10 (2021). The current definitive taxonomy of web-application risk classes. Ten categories reflecting real-world 2021-onwards data from OWASP contributors and CVE analysis. The community-standard reference every developer, auditor, and security engineer knows. Findings should map to A01 through A10 identifiers. The next revision is expected within the OWASP release cadence, but 2021 remains authoritative through 2026 for scoping and reporting.

OWASP Application Security Verification Standard (ASVS) v5.0. The verification-oriented standard OWASP publishes for defining testable security requirements. Where the Top 10 is a risk taxonomy, ASVS is a requirement taxonomy — 14 chapters, hundreds of individual verifiable requirements across three assurance levels (L1 opportunistic, L2 standard, L3 advanced). A serious WAPT report structures its verification coverage against ASVS chapters, so the client knows precisely which requirements were tested and which were out of scope.

OWASP API Security Top 10 (2023). The API-specific counterpart to the Top 10. Ten API-native risk classes reflecting how modern applications actually get breached at the API layer (which the general Top 10 covers only partially). Any WAPT of an API-heavy or API-only surface should tag against API1 through API10 identifiers explicitly.

OWASP Web Security Testing Guide (WSTG). The tester-facing procedural reference — a documented catalogue of individual test cases across every category of web-app testing (information gathering, config, identity, authentication, authorization, session, input validation, error handling, cryptography, business logic, client side, API testing). A well-run engagement's coverage sheet references WSTG test IDs so the client can verify what was and was not exercised.

Penetration Testing Execution Standard (PTES). The methodology-oriented framework for how pen-testing engagements should be structured — pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting. Serves as the procedural skeleton for the engagement.

NIST SP 800-115. US NIST's Technical Guide to Information Security Testing and Assessment. Overlaps with PTES on methodology. Cited by frameworks referenced in Indian federal and regulated-sector guidance. Useful for engagements that need to answer to both Indian and US procurement conversations.

Layer on:

CWE (Common Weakness Enumeration). Every finding tagged to a CWE identifier (CWE-79 XSS, CWE-89 SQLi, CWE-284 Improper Access Control, etc.). This is what developers grep against internal training material.
CVSS 3.1. Every finding scored on the CVSS 3.1 base metric with the vector string exposed. This is what security teams use for triage and prioritization.
MITRE ATT&CK. Where relevant, technique IDs (Initial Access, Credential Access, Discovery, Collection, Exfiltration, Impact) contextualize findings for threat-intel and detection teams.
DPDP Act 2023 + CERT-In. Sector overlay for Indian applications.
HIPAA + PCI-DSS + SOC 2. Sector overlays when applicable.

A finding without a framework tag is an anecdote. A finding tagged OWASP A01:2021 + CWE-284 + CVSS 3.1: 8.1 (High) + ASVS 5.0 §4.1.1 + WSTG-ATHZ-02 is defensible in front of any auditor, procurement office, or engineering leadership review.

Attack surface map of a modern web application#

Before naming techniques, know what an adversary sees. A minimal modern web application has this attack surface:

Front-end (browser code). HTML, CSS, JavaScript bundles, service workers, browser storage (localStorage, sessionStorage, IndexedDB), cookies. Every artifact loaded into the user's browser is inspectable by the user — including any secret naively embedded there.
API layer. REST endpoints, GraphQL resolvers, gRPC services, WebSocket channels, server-sent event streams. The primary interface an attacker probes. Authorization checks live here or they don't live at all.
Authentication subsystem. Login, signup, password reset, MFA enrollment, MFA challenge, session issuance, session refresh, session invalidation, OAuth/OIDC flows, SAML flows, API key management, service-to-service auth. Any weakness here becomes an account takeover.
Session management. Session token issuance (cookies, JWTs, opaque tokens), lifetime, rotation, revocation, binding to client attributes, cross-device synchronization. Weakness here becomes session hijacking or authorization bypass.
Business logic. The application's actual rules — who can do what, in which order, with which state transitions. Scanner-invisible by definition. Human-tester territory.
Backend services and data stores. Databases (SQL and NoSQL), caches (Redis, Memcached), object storage (S3, Azure Blob, GCS), search indices (Elasticsearch, OpenSearch), message queues (Kafka, RabbitMQ, SQS). Reachable via SSRF, via injection into query builders, via privilege escalation from an application-level foothold.
Third-party integrations. Payment gateways, KYC providers, SMS gateways, email providers, analytics SDKs, error-monitoring SDKs, feature-flag services, CDN configurations, single sign-on identity providers. Any of these can leak, mis-authorize, or be exploited to pivot inward.
File upload / download pipeline. Any surface accepting user-uploaded content — profile pictures, document attachments, imported spreadsheets, agent-consumed PDFs, avatar images. Historically the top pivot point for SSRF, RCE via processing libraries, and stored XSS.
Mobile companion app + web-view surfaces. If a mobile app talks to the same API surface, its behavior often diverges from the web client — sometimes with weaker validation.
Admin panel. Almost always weaker than the customer-facing product. Common pivot from a low-privilege customer account through an authorization gap.

Ten interfaces. Any one can be the pivot point. A WAPT enumerates each in scope, tests each with adversary-motivated techniques, and produces evidence per finding.

The OWASP Top 10 (2021) explained#

The current top ten, in category order, with what each actually means when you are on the offensive side of the engagement.

A01:2021 · Broken Access Control#

The number-one risk class in the 2021 revision, and consistently the highest-impact finding class across engagements. Access-control failures range from horizontal privilege escalation (user A reads user B's data via an ID in the URL — the "IDOR" pattern) to vertical escalation (customer role bypasses to admin functionality) to full multi-tenancy bypass (tenant A queries tenant B's data through a filter that only exists in the front-end).

Common patterns: authorization enforced only in the UI (front-end hides the button, backend accepts the call anyway); path parameters trusted without ownership check; batch/bulk endpoints that iterate over IDs without per-item authorization; JWTs whose claims are trusted without validation; role checks based on a client-sent header. Fix: authorization is code, not UI; check ownership on every object-level operation; deny by default; enforce tenancy filters in the persistence layer; centralize the authorization decision function and audit its call sites.

A02:2021 · Cryptographic Failures#

Sensitive data exposed in transit or at rest because cryptography is missing, weak, misconfigured, or misapplied. Historically called "Sensitive Data Exposure." Includes plaintext transmission of credentials, weak or deprecated TLS configurations, missing HSTS, sensitive data in URLs or logs, hardcoded encryption keys, weak KDFs (MD5 / SHA-1 for password hashing), and misuse of primitives (ECB mode, static IVs, RSA without padding, JWT alg:none acceptance).

Related pattern surfaced repeatedly on Indian SaaS engagements: JWT algorithm confusion attacks, where an application accepts a JWT signed with a different algorithm than its verification code assumes (see /blog/jwt-algorithm-confusion for the mechanics). Fix: TLS 1.2+ minimum, HSTS enforced; passwords hashed with a memory-hard KDF (Argon2id, scrypt, or bcrypt with cost factor ≥ 12); secrets in a secrets manager not in code; JWT libraries pinned to the intended algorithm.

A03:2021 · Injection#

Untrusted input interpreted as code or query by a downstream interpreter. Includes SQL injection, NoSQL injection, LDAP injection, OS command injection, expression-language injection, template injection, and less-obvious variants (XPath, XML external entity — though XXE has its own historical category, header injection, log injection).

Modern frameworks reduce the SQL-injection footprint dramatically when developers use parameterized queries consistently. Where injection surfaces in 2026: raw query strings in edge cases (search filters, dynamic ORDER BY, admin tools), NoSQL query objects built by concatenating user input, template rendering that trusts user-controlled variables, subprocess invocations that shell-out with user input. Fix: parameterization everywhere, input validation as defense in depth, principle-of-least-privilege on database accounts, no eval/exec/shell-out on user input.

A04:2021 · Insecure Design#

A category added in the 2021 revision to distinguish design-level flaws from implementation flaws. Missing rate limits, missing threat modeling, missing separation of duties, missing tenant isolation as an architectural principle, workflows that lack an authorization boundary between steps. Fix: threat modeling before implementation; secure design patterns as team defaults; explicit trust boundaries in architecture documents.

A05:2021 · Security Misconfiguration#

Missing hardening — verbose error messages leaking stack traces, default credentials shipped, unnecessary services exposed, missing security headers (CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy), directory listing enabled, permissive CORS policies, S3 buckets left public, cloud metadata endpoints reachable from application containers. Fix: hardening baselines automated in the deployment pipeline; security-header middleware as default; secrets rotated; cloud-account guardrails enforced.

A06:2021 · Vulnerable and Outdated Components#

Known-vulnerable dependencies in the software bill of materials. NPM, PyPI, Maven, Composer packages with published CVEs. Base container images with unpatched OS packages. Web-server versions with known exploits. Fix: SBOM generated at build; dependency scanning in CI (Dependabot, Snyk, Trivy); patching SLAs; container base-image refresh cadence.

A07:2021 · Identification and Authentication Failures#

Weak authentication mechanisms — no MFA on privileged accounts, weak password policies, credential stuffing not defended against, brute-force protection missing, session tokens predictable, session tokens not invalidated on logout, session fixation, insecure "remember me" implementations. Fix: MFA required for sensitive actions; passwords validated against known-breached lists (haveibeenpwned k-anonymity API); adaptive rate limiting; session tokens cryptographically random and rotated on privilege change.

A08:2021 · Software and Data Integrity Failures#

Trust in software or data updates without integrity verification. Unsigned software updates, insecure CI/CD pipelines, dependencies pulled from mutable sources, deserialization of untrusted data enabling remote code execution. Fix: signed releases, verified update channels, immutable dependency pinning, safe deserialization libraries only.

A09:2021 · Security Logging and Monitoring Failures#

Inability to detect an in-progress attack because logging is absent, incomplete, or unmonitored. Login failures not logged, high-value actions not logged, log storage tampered-with or lost, no alerting on anomalies. Fix: application logging standard covering auth events, authorization decisions, high-value business actions, admin actions; centralized log storage with integrity protection; alerting on abuse signals.

A10:2021 · Server-Side Request Forgery (SSRF)#

The application makes an HTTP request to a URL that is (partially) attacker-controlled. Attacker uses this to reach internal services, cloud-metadata endpoints (169.254.169.254 in AWS, 169.254.169.254 in GCP, metadata.google.internal), or otherwise-unreachable dependencies. Historically the pivot point in a large fraction of cloud-native breaches (Capital One 2019 remains the canonical example). Common surfaces: URL-fetching features (image proxies, webhook senders, RSS parsers, PDF renderers pulling remote resources, OG-tag preview generators). Fix: allow-list destinations rather than deny-list; disable cloud metadata endpoint reachability with hop-limit or metadata service v2 (IMDSv2 on AWS); DNS rebinding protection; separate network segments for outbound-fetching workloads.

The 2021 revision consolidated older categories (XXE folded into A03; broken authentication split between A01 and A07 depending on scope) and elevated SSRF to a first-class category based on incident data. Any WAPT report claiming "OWASP Top 10 aligned" should specifically reference OWASP Top 10 (2021).

The OWASP API Security Top 10 (2023) explained#

APIs deserve their own taxonomy because their attack surface differs from server-rendered web applications in material ways. The 2023 revision, in category order:

API1:2023 · Broken Object Level Authorization#

The API-layer version of A01. An API endpoint accepts an object ID (/api/v1/orders/{orderId}) and returns the object without checking whether the calling user owns it. Historically the most exploited API-layer issue and consistently the top finding class on API-only engagements. Fix: authorization check on every object-level operation, based on the authenticated identity, evaluated in code that developers cannot forget to include (middleware, ORM-level scoping, or a centralized authorization function).

API2:2023 · Broken Authentication#

Authentication implementation weaknesses at the API layer — missing MFA on sensitive API endpoints, weak API key entropy, API keys never rotated, JWT signing issues, refresh token abuse, password-reset flows exploitable, OAuth misconfigurations. Fix: robust authentication library, MFA where appropriate, key rotation policies, JWT algorithm pinning, secure OAuth 2.1 patterns.

API3:2023 · Broken Object Property Level Authorization#

Consolidation of the older "mass assignment" and "excessive data exposure" categories. Two failure modes. First: attacker sends fields the API silently accepts and applies — including fields that were not supposed to be user-editable (is_admin: true, verified: true, balance: 99999). Second: API returns object with fields the caller was not supposed to see (internal notes, moderation state, other users' hashed data, admin-only metadata). Fix: explicit allow-list of writable and readable fields per role; DTO patterns that never expose raw persistence models.

API4:2023 · Unrestricted Resource Consumption#

Missing rate limits, missing quotas, missing size caps enable resource-abuse attacks — denial of service, denial of wallet on cloud-metered resources, cost-explosion via expensive queries. Fix: rate limits at multiple layers (per-IP, per-user, per-endpoint, per-tenant); size caps on payloads; timeouts on downstream calls; queue depth limits.

API5:2023 · Broken Function Level Authorization#

Function-level (as opposed to object-level) authorization failures — a low-privilege user calls an admin-only endpoint that lacks the role check. Common where admin endpoints share a route prefix with user endpoints and rely on client-side routing to hide them. Fix: deny-by-default on all endpoints; authorization decision required and logged for every function.

API6:2023 · Unrestricted Access to Sensitive Business Flows#

Attacker automates a sensitive business flow (bulk account creation, credit-limit abuse, referral-program farming, ticket-scalping) faster or cheaper than the business model tolerates. Distinct from generic rate limiting — the abuse is business-model damaging even when each individual request is legitimate-looking. Fix: friction on sensitive flows (CAPTCHA, device fingerprinting, velocity checks), business-logic monitoring for abuse patterns, per-account and per-device throttles.

API7:2023 · Server-Side Request Forgery#

Same class as OWASP A10 — called out separately because APIs, being programmatic, frequently expose URL-consuming parameters (webhook targets, callback URLs, image fetchers, OAuth redirect URIs) at higher density than server-rendered apps. Fix: same as A10 (allow-list, IMDSv2, DNS rebinding protection, network segmentation).

API8:2023 · Security Misconfiguration#

API-layer version of A05. Verbose error responses leaking stack traces, permissive CORS (Access-Control-Allow-Origin: * on authenticated endpoints — a shockingly common finding), missing security headers on API responses, unnecessary HTTP methods enabled, debug endpoints exposed. Fix: hardening baseline for API responses, restrictive CORS, HTTP method allow-listing, no debug endpoints in production builds.

API9:2023 · Improper Inventory Management#

Old API versions still exposed after new versions ship (/api/v1/* still live after /api/v2/* migration), staging environments internet-reachable with weaker controls, undocumented endpoints ("shadow APIs") missed by inventory. Attackers scan for these; they are frequently weaker than the documented current version. Fix: API inventory as a living document; deprecation and decommissioning schedules; shadow-API discovery tooling; environment separation with distinct access controls.

API10:2023 · Unsafe Consumption of APIs#

The application's own consumption of third-party APIs is unsafe — trusting third-party API responses without validation, following redirects into untrusted destinations, deserializing third-party responses into privileged objects. Especially relevant for aggregator products, integration platforms, and any SaaS that stitches multiple third-party services. Fix: treat third-party API responses as untrusted input; validate, sanitize, and constrain their use.

A serious WAPT of an API-heavy product tags findings against both the OWASP Top 10 (2021) and the OWASP API Security Top 10 (2023) where applicable. The two are complementary, not overlapping.

Testing methodology: how a rigorous WAPT engagement runs#

Every engagement should follow a documented sequence with evidence at each stage. A six-phase model aligned with PTES + NIST SP 800-115 + OWASP WSTG.

Phase 1 — Reconnaissance. Passive OSINT on the target: subdomains, exposed staging environments, historical scanning data (Shodan, Censys), GitHub repos revealing internal endpoint patterns, LinkedIn tech-stack signals, breach-corpus checks for the target's domain. Public artifact scanning of any GitHub org, container registries, and any documentation surface.

Phase 2 — Enumeration. Active mapping of the application: authenticated crawling to enumerate endpoints, JavaScript inspection to surface API routes hidden from the UI, parameter mining, file-upload surface identification, admin panel discovery, third-party integration mapping. Coverage sheet is produced here so the client can verify scope was actually walked.

Phase 3 — Vulnerability analysis. Automated + manual probing against each identified surface. Automated pass with Burp Suite Pro, OWASP ZAP, sqlmap, dedicated authorization-testing tools, and framework-specific scanners. Manual pass on the surfaces where automation is weakest — authorization boundaries, business logic, session handling, custom crypto usage, file processing pipelines.

Phase 4 — Exploitation. Manual attack-chain construction. Every high-severity finding is proven end-to-end — from adversary action to concrete impact (sensitive data exfiltrated, privileged action executed, downstream system compromised, cross-tenant boundary crossed). No theoretical findings.

Phase 5 — Post-exploitation. Blast-radius quantification. If an authorization bypass succeeds, what data can be read, what actions can be taken, how many users are affected, what compliance clauses are triggered. The report has to answer "how bad is this?" not just "here's a broken authorization check."

Phase 6 — Report and retest. Executive summary (2-4 pages, decision-maker consumable), technical detail per finding (CVSS 3.1 with vector string, CWE tag, OWASP Top 10 + API Top 10 + ASVS mapping, reproduction steps, remediation guidance, references), retest of remediated findings within 60 days.

Evidence per finding minimum: reproduction request (curl or Burp export), affected response demonstrating impact, timestamp, environment, CWE + OWASP tags, CVSS 3.1 base score with vector string, remediation recommendation with example code where applicable.

Testing types: black-box, gray-box, white-box — when each fits#

Three engagement archetypes differing in the level of pre-engagement information the tester receives.

Black-box testing. Tester receives only the target URL and, optionally, a low-privilege test account. Emulates an external attacker with no insider knowledge. Advantages: realistic attacker perspective, no assumption of internal-doc access, useful for procurement demonstrations. Disadvantages: significant engagement time spent on reconnaissance and enumeration that a gray-box tester would receive as input; some deep issues (business logic across roles, admin-only functionality) may not be discovered without insider access. Best fit: initial engagements where the client wants to see what an outside attacker sees, or for compliance frameworks specifically requiring black-box.

Gray-box testing. Tester receives multiple test accounts across role tiers (customer, admin, tenant boundaries), API documentation, architecture overview, sometimes a code-flow walkthrough. Emulates an authenticated attacker who has done reconnaissance. Advantages: engagement time spent on finding issues rather than mapping surface; multi-tenant and role-boundary issues surface predictably; deep business-logic testing feasible; best return-on-engagement-cost ratio. Disadvantages: does not test the reconnaissance surface as rigorously. Best fit: the default recommendation for the majority of SaaS WAPT engagements, especially multi-tenant B2B products.

White-box testing. Tester receives everything above plus source-code access and internal architecture documentation. Emulates a fully-informed adversary or an insider threat. Advantages: deepest possible finding coverage; secure-code-review + WAPT combined engagement is achievable. Disadvantages: highest cost, requires the client to trust the tester with source-code custody. Best fit: pre-launch of a high-stakes product, prior to regulatory submission, or when a specific subsystem needs deep assurance.

Most Indian SaaS WAPT engagements land on gray-box as the default. Black-box adds cost without proportional finding value for a scoped engagement. White-box is worth the premium when the specific product justifies it (regulated healthtech, fintech handling money movement, security-sensitive infrastructure).

Authentication + session management testing#

Consistently the highest-density finding area across engagements. A dedicated portion of every WAPT should cover this surface, because authentication and session weaknesses convert directly into account takeover — the fastest, most damaging exploitation chain.

Test areas covered by a rigorous authentication + session review:

Login flow. Rate limiting on failed attempts, account lockout policy correctness, credential-stuffing defenses, error messages that avoid user-enumeration signals, response time consistency preventing timing-based enumeration, MFA challenge if enabled.
Signup flow. Email verification enforcement, disposable-domain filtering (if in scope), duplicate account prevention, invitation-token security.
Password reset. Reset-token entropy, single-use enforcement, expiry window, delivery channel (email, SMS), out-of-band verification, session invalidation on password change, race-condition handling.
Session token issuance. Cookie flags (Secure, HttpOnly, SameSite), JWT signing algorithm pinning, token lifetime, refresh token rotation, binding to client attributes where appropriate.
Session lifecycle. Logout invalidation server-side (not just client-side cookie removal), session revocation on password change, MFA-enrollment change triggering re-authentication, concurrent-session handling if the product supports it.
MFA enrollment + challenge. TOTP secret entropy, backup codes single-use, recovery flow authentication strength, WebAuthn implementation correctness if used.
API-key management. Entropy, storage (hashed in the database, never plaintext), rotation, per-key rate limits, scoping to specific operations, revocation propagation.
OAuth 2.1 / OIDC flows. State parameter enforcement, PKCE for public clients, redirect-URI allow-list strictness, token audience validation, refresh token rotation.
JWT-specific. Algorithm pinning (reject none, reject algorithm confusion), signature verification before claim consumption, expiry (exp) enforcement, audience (aud) and issuer (iss) validation, key rotation via kid header handled safely (see /blog/jwt-algorithm-confusion for detailed treatment).
SSO flows. SAML signature validation (XML signature wrapping resistance), assertion replay prevention, session mapping to the local application user.
Password storage. Argon2id, scrypt, or bcrypt (cost ≥ 12); no MD5, no SHA-1, no unsalted SHA-256, no home-brew KDFs.

Findings map to OWASP A07:2021, API2:2023, CWE-287 (Improper Authentication), CWE-384 (Session Fixation), CWE-613 (Insufficient Session Expiration), CWE-798 (Hardcoded Credentials), among others.

Business logic testing — why scanners miss it#

Automated scanners cannot test business logic because business logic requires understanding what the application is supposed to allow, and no signature encodes that. A scanner does not know that a discount code should only apply once, that a bank transfer should require MFA above ₹1L, that a support agent should not be able to read messages between two customers, or that a referral bonus should only pay out after the referred user completes onboarding. These are rules encoded in your application, and only a human who read the specification (or reverse-engineered it from the UI) can test them.

Common business-logic finding classes:

State-transition bypass. Order status can be forced from pending_payment directly to shipped via a status-update endpoint that skips the payment-verification step.
Workflow-skipping. Multi-step forms whose intermediate validation is only enforced client-side; attacker submits the final step with fabricated intermediate state.
Race conditions. Two simultaneous requests to redeem a single-use coupon both succeed because the "already-redeemed" check is not transactional.
Numeric edge cases. Negative quantities on order lines, negative amounts on refunds, integer overflow on discount calculations.
Time-of-check to time-of-use (TOCTOU). Balance is checked, then updated in a non-atomic sequence, allowing double-spend.
Referral / rewards abuse. Self-referral loops, sockpuppet account chains, reward-farming beyond intended business-model tolerance.
Multi-tenant boundary violation via logic. Feature that lets a tenant admin invite a user by email; the invite flow assigns the invited user to the admin's tenant without verifying the invited user isn't already in a different tenant.
Rate limits circumvented by business-flow legitimate patterns. Attacker discovers a legitimate-looking sequence that achieves the equivalent of a rate-limit bypass without triggering the rate-limiter's heuristic.

Testing methodology: threat-model the flow before probing it. Enumerate the intended user actions and the intended constraints on each. Then probe each constraint by attempting to violate it in every way an attacker with unlimited patience could think of. This is genuine human work — no framework catalogues every possible logic flaw because the flaws are application-specific.

API testing specifics — REST, GraphQL, gRPC#

Different API paradigms surface different classes of finding. A WAPT covering an API-heavy product needs paradigm-specific testing.

REST APIs. The mainstream case. Testing covers object-level authorization on every ID-taking endpoint, function-level authorization on every route, mass-assignment on every write endpoint, excessive data exposure on every read endpoint, rate limits on sensitive operations, HTTP method allow-listing (avoid PUT/DELETE accepting when the endpoint only intends GET), pagination-based enumeration limits, and standard input validation.

GraphQL APIs. Distinct attack surface. Testing covers introspection exposure (should typically be disabled in production), query depth limits (unbounded nesting enables DoS), query complexity limits, resolver-level authorization (every resolver enforces authorization, not just the top-level query), batching abuse (a single request containing thousands of sub-queries), field-level authorization on sensitive fields, mutation authorization especially on state-changing mutations, and IDOR patterns via GraphQL IDs.

gRPC APIs. Increasingly common for internal service-to-service traffic exposed externally as a stability-oriented alternative to REST. Testing covers method-level authorization, message-size limits, streaming abuse (long-lived streams as DoS), TLS configuration on the gRPC channel, and reflection-endpoint exposure (should typically be disabled in production).

WebSocket / Server-sent events. Testing covers upgrade authentication (session token validated on the upgrade request), authorization on each message not just on connection, message rate limits, message size limits, and origin validation (Origin header check).

Webhook receivers. Testing covers signature verification correctness, replay protection (nonce or timestamp window), TLS enforcement, and SSRF exposure on any URL-taking webhook-target configuration.

Findings map to OWASP API Security Top 10 (2023) predominantly, with CWE and CVSS tags per finding.

Client-side testing — XSS, CSRF, prototype pollution, DOM-based attacks#

The browser-side of a web application is its own attack surface. Testing coverage:

Cross-Site Scripting (XSS). Three variants. Reflected XSS — attacker-crafted URL with a payload that reflects into the response. Stored XSS — attacker-submitted payload persisted server-side and rendered to other users. DOM-based XSS — payload interpreted by client-side JavaScript without reaching the server (via location.hash, postMessage, document.referrer, etc.). Fix: contextual output encoding, Content Security Policy (CSP) enforced with nonce or hash-based script sources, dangerouslySetInnerHTML and equivalents banned unless input is provably safe.

Cross-Site Request Forgery (CSRF). Attacker-controlled site causes the victim's browser to submit an authenticated request to the target application. Modern mitigations (SameSite cookies as Lax or Strict by default in current browsers) reduce the surface substantially. Still relevant on non-cookie-based auth, cross-origin form submissions, and legacy browsers. Fix: SameSite=Strict or Lax on session cookies; CSRF tokens on state-changing endpoints; check Origin and Referer headers.

Prototype pollution. JavaScript-specific finding class where attacker-controlled input pollutes Object.prototype, affecting the behavior of unrelated code downstream. Increasingly common in Node.js server-side and modern front-end frameworks. Fix: use Map instead of plain objects for user-controlled keys; freeze Object.prototype; use libraries hardened against the pattern (lodash post-4.17.21).

postMessage abuse. Cross-origin postMessage receivers that trust message data without validating event.origin become attack surface for any embedded iframe or opener. Fix: validate event.origin against an allow-list on every receiver.

Clickjacking. Target application framed in an attacker-controlled page; user's clicks on the invisible frame trigger actions in the target. Fix: X-Frame-Options: DENY or CSP frame-ancestors 'none' (or a strict allow-list) on all pages not intended to be framed.

Open redirects. Application redirects to a user-controlled URL, enabling phishing chains where the initial URL appears legitimate. Fix: allow-list redirect destinations; if arbitrary redirect is required, warn the user with an interstitial.

Sensitive data in browser storage. Session tokens in localStorage (accessible to any XSS), API keys embedded in front-end bundles, PII cached in IndexedDB without expiration. Fix: session tokens in HttpOnly cookies; secrets never in front-end code; sensitive local caches with explicit expiry and clearing on logout.

Findings map to OWASP A03:2021 (Injection, for XSS as a subset), CWE-79 (XSS), CWE-352 (CSRF), CWE-1321 (Prototype Pollution), CWE-451 (Clickjacking), CWE-601 (Open Redirect).

Common findings + real-world impact patterns#

Patterns seen across engagements against Indian SaaS in the 2024-2026 window:

Broken Object Level Authorization (IDOR) on API endpoints in 70%+ of first-time engagements. The single most common high-severity finding class. Object IDs in URLs, no ownership check, cross-tenant data readable by any authenticated user with a scripting hobby.
Mass assignment on user-profile-update endpoints in 40-60% of cases. Client sends is_admin: true in the profile-update payload; the ORM silently applies it.
JWT algorithm confusion or weak JWT verification in 20-30% of JWT-using applications. Either none algorithm accepted, or asymmetric-vs-symmetric confusion allowing a public key to be used as an HMAC secret.
Missing rate limits on login and password-reset endpoints in 50%+ of cases. Enables credential stuffing at production speed; enables user-enumeration timing attacks.
Verbose error responses leaking stack traces in 60%+ of pre-hardening applications. Framework versions, ORM library versions, internal paths, sometimes database column names — all disclosed on any triggered error.
Server-side request forgery on file-upload / image-fetch endpoints in 20-30% of cases where such features exist. Modal exploitation chain pivots into cloud-metadata credentials on AWS applications without IMDSv2.
Cross-tenant leakage via shared caches or search indices in 15-25% of multi-tenant applications. Tenant isolation enforced at the primary database layer but forgotten at the search-index or cache layer.
CORS wide open on authenticated API endpoints in 30-40% of cases. Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true (which browsers correctly reject, but the presence of the pair signals a misunderstanding of the specification that manifests as exploitable variants nearby).
File-upload processing chain enabling stored XSS or SSRF in 40%+ of applications accepting uploads. SVG uploads rendered as images execute embedded scripts; PDF or Office document processing pulls external resources.
Admin panel accessible from customer network segments in 40-50% of internal audits. No network-level separation between the customer-facing product and the internal admin interface; a compromised customer account is one authorization gap away from admin functionality.

The findings themselves are not novel; every OWASP category catalogues them. What is consistently novel is the client's surprise at which of these are present in their specific system. Almost every team believes they have covered these already. Almost every team is wrong about at least two.

Deliverables of a WAPT engagement#

What a serious engagement should hand you at the end:

Executive summary (2-4 pages). Business-language narrative of security posture, top findings ranked by risk, boardroom-consumable. Includes an overall risk rating, comparison to peer baselines where possible, and a prioritized remediation roadmap.
Technical findings report (typically 30-80 pages depending on scope). Every finding with: title; OWASP Top 10 (2021) + OWASP API Security Top 10 (2023) + ASVS + WSTG mapping; CWE identifier; CVSS 3.1 base score with vector string; affected components; reproduction steps (copy-pasteable, ideally as a curl command or a Burp export); evidence artifacts (screenshots, captured requests/responses, tool output); remediation guidance with code or configuration examples where applicable; references to primary framework sources.
Reproduction package. Scripts, payloads, sample requests, and any custom tooling used during the engagement. Handed over so the client's team can re-verify the fixes themselves.
Attack-flow diagrams. For multi-step high-severity findings, a diagram showing the exploitation chain — initial entry point through the affected components to the ultimate impact.
Framework mapping tables. Findings cross-tabulated against OWASP Top 10, OWASP API Top 10, ASVS chapters, CWE identifiers, MITRE ATT&CK techniques where applicable, and any client-relevant compliance framework (DPDP Act, HIPAA, PCI-DSS, SOC 2 CC-series controls).
Remediation-priority matrix. Findings ranked by exploitability × business impact, with recommended fix owner and rough effort estimate (S / M / L days of engineering work).
Retest report. Delivered after client remediation, confirming which findings are closed, which are partially addressed, which remain, and which are accepted-with-rationale.
Coverage sheet. WSTG test IDs and ASVS requirements attempted during the engagement, with pass / fail / not-applicable / out-of-scope markers. Lets the client see what was actually tested — critical for procurement conversations that ask "was X tested?"
Optional readout call. 30-60 min live walkthrough with client's engineering + security teams to answer questions and prioritize.

A report that arrives as a PDF and nothing else is a report, not an engagement. The reproduction scripts, the coverage sheet, and the retest are what convert findings into fixes and evidence into procurement leverage.

Scoping: cost, timeline, engagement types#

Common WAPT engagement shapes in the Indian market as of 2026:

Mini vulnerability assessment (2-5 business days, ₹25-75k). Broad automated scanning augmented with a light manual pass on obvious surfaces. Delivers a short report identifying whether a full engagement is warranted. Useful for founders who want to know if there are open low-hanging issues before committing budget to a full WAPT.
Focused WAPT (5-10 business days, ₹75k-1.5L). Deep-dive on a bounded scope — one product surface, one API subset, one specific feature. Gray-box by default. Recommended for teams with a specific concern (a new feature they want tested pre-launch, a particular API they know is under-tested).
Full WAPT engagement (10-20 business days, ₹1.5-3L). Comprehensive testing of a production web application: front-end, API layer, authentication, session, business logic, backend integration points, uploads. Executive + technical report + retest. The default recommendation for annual compliance-driven engagements.
Combined WAPT + API pen test (15-25 business days, ₹2-4L). Applicable when the product's API surface is substantial and API-only clients exist alongside the web front-end. Both OWASP Top 10 and OWASP API Security Top 10 as scope references.
White-box WAPT with source-code review (15-30 business days, ₹3-6L). Deepest possible engagement. Combines dynamic testing with secure-code review on the highest-risk modules. Suitable for regulated products, pre-launch, or pre-audit assurance.
Continuous WAPT retainer (monthly, ₹75k-2L/month). Recurring pressure on a system that evolves rapidly — feature releases weekly, new endpoints frequently. Retained team runs a lighter sweep every sprint and a deeper engagement quarterly.
Incident-response support (T&M, ₹10-25k/hour). Post-incident forensic reconstruction of what a web-application breach looked like and how to prevent recurrence.

Fixed-fee pricing preferred over T&M for defined scopes — reduces client anxiety, aligns incentives on completion not billable hours. Retainer + T&M hybrid works for ongoing engagements. Beware of quotes materially below these ranges — the delta is usually made up in reduced manual testing depth (mostly automated scanning with a rebadged scanner report), missing retest, or shallow reporting.

What to do BEFORE calling a WAPT firm (readiness checklist)#

Save your engagement budget by resolving obvious issues in advance. Before scoping a WAPT, verify:

Teams that check these boxes get more value from an engagement — the tester spends time on subtle attack chains rather than obvious misconfigurations. Teams that skip these often receive reports dominated by findings they could have self-remediated for zero cost.

DPDP Act 2023 + WAPT: compliance overlay for Indian SaaS#

India's Digital Personal Data Protection Act 2023, in force since 2023 with subordinate MeitY rules progressively enacted through 2024-2026, applies to any Data Fiduciary processing personal data of Data Principals located in India. Web applications processing personal data — nearly all customer-facing and B2B SaaS products — are in scope.

Key intersection points with WAPT:

Section 8 (Data Breach Notification). If a WAPT finding demonstrates a route to unauthorized personal-data disclosure, and if any subsequent incident actualizes that route, notification obligations trigger. Better to fix pre-notification than to notify. WAPT findings involving personal data should be tagged with DPDP applicability alongside OWASP + CWE tags.
Section 5 (Notice). Personal-data processing purpose must be disclosed. WAPT findings that expose data being processed beyond the notified purpose (through logging, analytics, cross-purpose reuse) constitute a compliance issue distinct from the technical vulnerability itself.
Section 11 (Right to Correction and Erasure). Data Principal erasure requests must actually delete personal data. WAPT should verify that erasure requests propagate through caches, search indices, backups (per retention policy), and any downstream analytics pipelines.
Data Fiduciary + Data Processor obligations. If your web application uses third-party services (SMS gateways, email providers, analytics SDKs) that process personal data, contractual data-flow constraints must be enforced by more than a written agreement. WAPT should verify technical controls match the contractual promises.
Significant Data Fiduciary designation. Certain volumes or categories of data trigger enhanced obligations, including a Data Protection Impact Assessment (DPIA). WAPT findings feed the DPIA.
Consent-management surface. Consent capture, consent withdrawal, and consent-scoped data access are testable surfaces. Broken consent enforcement is a DPDP compliance finding even if no data breach has occurred.

Findings involving personal data should be tagged with DPDP applicability alongside OWASP + CWE tags. Auditors and regulators expect this level of specificity from Indian SaaS as the market matures.

HIPAA + WAPT for Indian healthtech serving US patients#

Indian healthtech products serving US-based patients — telemedicine platforms, health-record aggregators, medical-imaging services, clinical-workflow SaaS, US-facing telehealth apps built in India — are subject to the US Health Insurance Portability and Accountability Act (HIPAA) as Business Associates of the US Covered Entities they serve.

Key WAPT intersection points:

HIPAA Security Rule §164.308(a)(1)(ii)(A) — Risk Analysis. Requires periodic technical evaluation of security posture. WAPT satisfies part of this requirement as an "evaluation" activity.
§164.308(a)(8) — Evaluation. Requires periodic technical and non-technical evaluation of security controls. Annual WAPT is the standard technical fulfillment.
§164.312(a)(1) — Access Control. Requires unique user identification, emergency access procedure, automatic logoff, encryption. WAPT tests all of these directly.
§164.312(b) — Audit Controls. Requires activity logging on systems containing electronic Protected Health Information (ePHI). WAPT can verify logging is present and functional.
§164.312(c) — Integrity. Requires controls to prevent unauthorized alteration of ePHI. WAPT tests for injection, mass-assignment, and race conditions that could enable this.
§164.312(e) — Transmission Security. Requires encryption in transit. WAPT verifies TLS configuration.
Breach Notification Rule. A HIPAA breach — unauthorized acquisition, access, use, or disclosure of unsecured ePHI — triggers notification obligations to individuals, the US Department of Health and Human Services, and (for large breaches) media. WAPT findings involving ePHI-exposure routes are remediation priorities specifically to avoid this trigger.
Business Associate Agreement (BAA). The BAA between the Indian healthtech and its US Covered Entity customer will typically require regular technical safeguards evaluation — WAPT satisfies the letter of that requirement.

Indian healthtech serving US patients should scope WAPT with explicit HIPAA overlay tagging — findings involving ePHI-adjacent surfaces flagged separately, with mapping to specific HIPAA Security Rule sections.

Integration with AI red-team + ISO 42001 readiness#

WAPT is one leg of a broader offensive-security program. Two adjacent engagements come up frequently for AI-native Indian SaaS in 2026.

AI red-teaming. If your web application incorporates AI features — chat assistants, RAG-backed search, agentic tools, LLM-generated content — the AI surface is a distinct engagement scope with distinct techniques and distinct framework anchoring (OWASP LLM Top 10 v2.0, MITRE ATLAS, NIST AI RMF). WAPT tests the wrapping web application; AI red-teaming tests the AI system inside. Both are needed, and they are best scoped as separate engagements with reconciled reporting. See /blog/ai-red-teaming-complete-guide-2026 for the full treatment.

ISO/IEC 42001 readiness. For AI-native SaaS pursuing ISO/IEC 42001:2023 (AI Management System) certification, WAPT + AI red-team results together feed multiple control clauses in the AIMS. Sequencing matters: run the technical assessments, remediate the findings, then engage with a certification body with the evidence already in hand. See /blog/iso-42001-readiness-complete-guide-india-2026 for the full readiness pathway.

A serious 2026 Indian AI-native SaaS security posture combines: continuous vulnerability scanning (baseline), annual WAPT (compliance and enterprise procurement), AI red-team on the AI surface (LLM-specific coverage), and ISO 42001 readiness engagement (governance evidence). Each layer covers what the others do not.

How The Zyber Security approaches WAPT#

The engagement model is designed for Indian SaaS companies serving regulated-industry and enterprise buyers. Three principles govern how The Zyber Security scopes and delivers.

Evidence over opinion. Every finding ships with a reproducible payload (curl command, Burp export, or scripted PoC), a captured request/response pair, and a scoring rationale. If it cannot be reproduced under scope, it does not go in the report. If it can, the report includes the exact request the client can rerun to verify remediation.

Framework-anchored reports. Every finding tags OWASP Top 10 (2021), OWASP API Security Top 10 (2023) where applicable, CWE identifier, CVSS 3.1 base score with vector string, ASVS v5 requirement where applicable, WSTG test ID where applicable, and any client-relevant compliance framework (DPDP Act, HIPAA, PCI-DSS, SOC 2, RBI / SEBI / IRDAI). Auditors read the tags. Developers read the fixes. Executives read the summary. One report, three audiences.

Retest included, always. After the client remediates, The Zyber Security re-verifies. The engagement is not closed until findings are demonstrably fixed or accepted-with-documented-rationale. Retest occurs within 60 days of the initial report delivery, at no additional cost within the same engagement scope.

Scoping options and current pricing are documented at /services/web-application-pen-testing. A mini vulnerability assessment is the fastest way to know whether a full engagement is warranted for a specific application. Contact via /contact for scoping conversations.

Where this maps#

OWASP Top 10 (2021) — A01 through A10, full coverage
OWASP Application Security Verification Standard (ASVS) v5.0 — chapters 1 through 14, coverage scoped per engagement
OWASP API Security Top 10 (2023) — API1 through API10, full coverage for API-heavy engagements
OWASP Web Security Testing Guide (WSTG) — test IDs referenced in the coverage sheet
Penetration Testing Execution Standard (PTES) — methodology framework
NIST SP 800-115 — methodology framework
CWE — CWE-79 (XSS), CWE-89 (SQLi), CWE-284 (Improper Access Control), CWE-287 (Improper Authentication), CWE-352 (CSRF), CWE-384 (Session Fixation), CWE-601 (Open Redirect), CWE-798 (Hardcoded Credentials), CWE-918 (SSRF), CWE-1321 (Prototype Pollution) — as applicable per finding
CVSS 3.1 — base score with vector string on every finding
MITRE ATT&CK — Initial Access (TA0001), Credential Access (TA0006), Discovery (TA0007), Collection (TA0009), Exfiltration (TA0010), Impact (TA0040) — technique IDs per finding where relevant
DPDP Act 2023 — Sections 5 (Notice), 8 (Data Breach Notification), 11 (Right to Correction and Erasure)
HIPAA Security Rule — §164.308 (Administrative), §164.312 (Technical) — for Indian healthtech serving US patients
CERT-In Cyber Incident Reporting — for incidents affecting Indian assets

FAQ#

How is web application penetration testing different from a vulnerability scan? A vulnerability scan is automated tooling running signature matches against your application. Coverage is broad, findings are shallow, false positives are common, and business-logic issues are entirely invisible to the tool. A penetration test is human operators augmenting scanner output with manual testing, chain-building, business-logic analysis, and adversary emulation. Every finding is validated end-to-end. A scanner report is not a WAPT report, and no serious enterprise procurement office will accept one as such.

How often should we run a WAPT? Baseline: annually. On any major architecture change (auth migration, multi-tenant expansion, new API surface, cloud provider migration), an additional engagement is warranted. Rapidly evolving products benefit from a continuous retainer model. Compliance-driven engagements (HIPAA, RBI, SEBI, IRDAI, ISO 27001) typically specify annual cadence explicitly.

Can WAPT be done fully automatically, without human testers? Partially. Automated scanners, dependency vulnerability tools, and secret-scanning tools can run at machine scale and catch a substantial fraction of surface-level issues. Business logic, multi-tenant boundary testing, chain-building across findings, and blast-radius analysis are human work as of 2026. AI-augmented tooling is a productivity multiplier for human testers, not a replacement.

What is the difference between VAPT and WAPT? VAPT is a broader term — "Vulnerability Assessment and Penetration Testing" — often used in Indian regulatory contexts (RBI, SEBI, IRDAI) to describe the combined offering. WAPT is specifically the web-application scope within that broader offering. A VAPT engagement may include WAPT, network pen testing, cloud configuration review, and mobile pen testing depending on scope. When a regulator or enterprise buyer asks for a "VAPT report," they typically expect coverage across whatever attack surfaces the target actually has.

Do you provide CERT-In-empanelled testing? Empanelment status varies over time. Prospective clients requiring CERT-In-empanelled testing should confirm current empanelment directly during scoping. Note that many enterprise procurement contexts accept non-empanelled testing when the testing firm can demonstrate rigorous methodology, OSCP / CREST / Offensive Security certified testers, and framework-mapped reporting.

Should we test staging or production? Both have tradeoffs. Staging is safer — no risk of production impact — but must be a faithful replica of production for findings to translate. Production testing is more realistic but requires explicit change-window scoping, data-handling agreements, and rollback plans. The default recommendation is staging for the primary engagement, with a light production verification pass on non-destructive findings to confirm they translate. Payment flows and irreversible actions are always tested in staging.

We're pre-launch — should we still test? For pre-launch systems, a combined threat-modeling + design-review engagement is often more cost-effective than a full WAPT. Architecture, authentication design, tenant isolation model, and API-surface design are reviewed before implementation, catching problems when they are cheap to fix. Full WAPT once the system is production-shaped. Pre-launch and post-launch engagements are both worth budgeting for on high-stakes products.

How do you handle client data during testing? Data-handling policy is per-engagement, documented in the Statement of Work, and constrained by the Data Processing Agreement. Default: test data only, no production PII touched unless explicitly scoped. All artifacts encrypted at rest, deleted per retention policy at engagement close, never used for training any downstream system or reused across clients.

Can WAPT be scoped alongside AI red-teaming or a network pen test? Yes, and often should be. WAPT + AI red-team (if the product has AI surface) + network pen test of the deployment infrastructure covers the full stack. Scoped together, findings can be reconciled into one integrated report with a single executive summary — reducing the reporting overhead the client's leadership has to consume.

What does a good outcome from a WAPT engagement look like? Zero unresolved-high or unresolved-critical severity findings after retest. Documented mapping from findings to OWASP, ASVS, CWE, and any relevant compliance framework. Client's engineering team confident they can rerun the payloads themselves for regression testing. Executive team with a defensible web-application security posture narrative for enterprise procurement, regulatory conversations, and board reporting. Scoped renewal on the calendar for the next cycle.

WAPTWeb Application SecurityOWASP Top 10OWASP API Security Top 10OWASP ASVSPenetration TestingDPDP ActHIPAAIndian SaaS

Related service

Web Application Pen Testing

OWASP-plus testing for modern web + API stacks.

See how we test it