OWASP ZAP: Free Automated Web Scanning for Indian Teams

OWASP ZAP (Zed Attack Proxy) is a free, open-source web application scanner that finds common vulnerabilities — XSS, SQL injection, insecure headers, exposed debug endpoints — by crawling your site and probing it the way an attacker's tooling would. For Indian SMB teams with no dedicated security engineer, ZAP is the single best starting point: no license cost and enough automation to run inside a CI/CD pipeline. This guide covers the spider and AJAX spider, passive versus active scanning, authenticated scan contexts, the Automation Framework, CI/CD baseline scans, triaging false positives, and where ZAP's coverage stops and a manual VAPT engagement has to pick up.

Why Start With OWASP ZAP

Most Indian SMBs ship a web app or customer portal with zero automated security testing between releases. The gap isn't awareness — it's that manual penetration testing is episodic, usually once or twice a year, while code ships every week. OWASP ZAP closes that gap for the bugs that don't need a human: missing security headers, verbose error pages, outdated JavaScript libraries, obvious injection points, and misconfigured cookies.

Spider vs AJAX Spider: Mapping the Application

Before ZAP can scan anything, it needs to know what pages exist. That's what the two crawlers do, and picking the wrong one is the most common reason a first ZAP scan comes back nearly empty.

The traditional spider follows <a href> links and HTML forms found in server-rendered page source. It's fast and works well on classic multi-page sites, WordPress installs, and server-rendered admin panels.

The AJAX spider drives a real browser (via Selenium) to execute JavaScript and discover content that only appears after a script runs — which describes most modern React, Vue, and Angular front ends. If your app is a SPA and you only run the traditional spider, ZAP will report "no vulnerabilities found" not because your app is secure, but because it never saw past the loading screen.

Passive Scan vs Active Scan: Know the Difference Before You Click "Attack"

This distinction matters more than any other setting in ZAP, because getting it backwards can take down a production service.

Authentication Contexts: Scanning Behind the Login Wall

Unauthenticated scanning only tests the public-facing surface of your app. The vulnerabilities that actually matter on a SaaS product or customer portal usually live behind authentication: the dashboard, the admin panel, the billing page, the API a logged-in user calls.

ZAP handles this through Contexts, which bundle together the scope (which URLs are in play), the authentication method, and session-handling rules:

1. Define a Context and scope it to your target's in-scope URLs.
2. Configure the authentication method — form-based login, JSON-based login, script-based auth for SSO/OAuth flows, or manual login where you record a sequence.
3. Set up a user with valid test credentials specific to the scan environment — never production customer credentials.
4. Configure session management so ZAP detects when it has been logged out (a common failure mode where a scan silently runs unauthenticated after the first session timeout).
5. Add a logged-in/logged-out indicator — a regex ZAP checks against each response to confirm session state.

The Automation Framework: Making ZAP Repeatable

Manually clicking through ZAP's desktop UI works for a one-off assessment, but it doesn't scale to a team shipping weekly. The ZAP Automation Framework solves this with a YAML plan that defines the entire scan as code — target, context, spider settings, active scan policy, and report output — so the same scan runs identically every time, including from a CI runner.

A minimal automation plan looks conceptually like this:

env:
  contexts:
    - name: MyApp
      urls: [https://staging.example.in]
jobs:
  - type: spider
  - type: spiderAjax
  - type: passiveScan-wait
  - type: activeScan
  - type: report
    parameters:
      template: risk-confidence-html

Because the plan is a version-controlled file, security testing configuration goes through the same code review as everything else — no tribal knowledge locked in one person's desktop ZAP session.

Baseline Scans in CI/CD

For teams that want coverage on every pull request without the cost of a full active scan, ZAP ships purpose-built Docker images: a baseline scan that spiders the target and runs passive rules only, then fails or warns the build — fast enough for CI, safe enough for staging.

A typical CI wiring runs the baseline image against every staging deploy, publishes the report as a build artifact, and gates merge only on high-confidence, high-risk findings — treating everything else as a tracked backlog item. Full active scans, slower and riskier, are better scheduled on a recurring window against staging rather than every commit.

Triaging False Positives

A raw ZAP report from a real application is rarely a clean list of exploitable bugs — it's a mix of genuine findings, informational noise, and false positives, and treating every alert as equally urgent burns credibility with engineering fast.

Work through alerts using ZAP's built-in risk and confidence ratings together, not risk alone. A "High risk, Low confidence" alert on a reflected-XSS pattern the framework already auto-escapes is a classic false positive; a "Medium risk, High confidence" missing Content-Security-Policy header deserves more attention than its label suggests. Common false-positive sources:

1. Framework auto-escaping — many frameworks neutralise the exact payload ZAP sent, but ZAP still flags the reflection pattern.
2. WAF or CDN interference — a scan run through a WAF can produce alerts about the WAF's own error pages, not your application.
3. Duplicate alerts — the same underlying issue reported once per URL parameter, inflating the apparent count.
4. Informational alerts treated as vulnerabilities — comments in source or timestamp disclosure is context for a human, not an actionable finding alone.

Where ZAP Stops and Manual VAPT Starts

ZAP is genuinely good at pattern-matching known vulnerability classes across every page and parameter it can reach. It is structurally unable to do several things a manual tester does routinely.

Getting Started This Week

For a team with no existing security tooling, a realistic first step looks like this: install ZAP or pull the Docker baseline image, point it at a staging copy of your application, run the spider and AJAX spider together, review the passive scan results first since they're zero-risk, then schedule an authorised active scan during a low-traffic window. Wire the baseline scan into CI once the manual run is clean, so every future deploy gets checked automatically.

Platforms like Bachao.AI build continuous automated scanning — including ZAP-class coverage — into a broader VAPT pipeline purpose-built for Indian SMBs, so teams get always-on visibility without owning scan infrastructure themselves. Dhisattva AI Pvt Ltd designed the platform around exactly this gap: the tooling is free, but most SMBs lack the in-house time to run and triage it consistently.

Next Steps

Automated scanning with OWASP ZAP is the right free first step for any Indian team that has shipped a web app with no security testing in place. It will not replace a manual penetration test — but it will catch a meaningful share of real issues before an attacker or an auditor does, at zero licensing cost.

Ready to go beyond automated scanning? Get a free VAPT scan, or browse the Bachao.AI blog for more hands-on security guides. If your organisation processes personal data, also review our DPDP compliance guide.