OWASP ZAP
Overview
OWASP ZAP is an open-source web application security scanner that discovers vulnerabilities through spidering, passive analysis, and active attack testing. It detects OWASP Top 10 issues (XSS, SQL injection, CSRF, SSRF, broken access control), integrates with CI/CD via Docker and GitHub Actions, and supports API scanning from OpenAPI specs with configurable scan policies.
Instructions
- When running quick scans in CI, use
zap-baseline.py which performs passive-only scanning (non-destructive) on every PR and catches approximately 60% of issues without sending attack payloads.
- When running thorough scans on staging, use
zap-full-scan.py which combines spidering, passive scanning, and active attack testing; never run active scans on production since they send destructive payloads.
- When scanning APIs, use
zap-api-scan.py with the OpenAPI/Swagger spec to automatically discover and test all endpoints without manual crawling.
- When configuring authentication, set up form-based, script-based, or header-based auth before scanning so ZAP can reach authenticated endpoints that contain the majority of vulnerabilities.
- When integrating with CI/CD, use the Docker image (
ghcr.io/zaproxy/zaproxy) or GitHub Actions (zaproxy/action-baseline), set fail thresholds by alert level, and generate both HTML and JSON reports.
- When triaging results, prioritize by confidence and risk level (High/High first), exclude known false positives with scan policy rules, and ignore Informational alerts in CI.
Examples
Example 1: Add security scanning to a CI/CD pipeline
User request: "Run OWASP ZAP on every pull request to catch security issues early"
Actions:
- Add a GitHub Action using
zaproxy/action-baseline@v0.12.0 targeting the staging URL
- Configure fail thresholds to break the build on High risk alerts only
- Generate HTML reports as build artifacts for developer review
- Add scan policy exceptions for known false positives
Output: A CI pipeline that runs passive security scanning on every PR with reports and configurable failure thresholds.
Example 2: Run a full security audit on a staging environment
User request: "Perform a comprehensive security scan of our web application before launch"
Actions:
- Configure ZAP authentication with the application's login flow
- Run the Ajax Spider for JavaScript-heavy SPA crawling
- Execute a full active scan with High strength on all discovered endpoints
- Generate HTML and JSON reports, triaging alerts by confidence and risk
Output: A comprehensive security audit report with prioritized vulnerabilities and remediation guidance.
Guidelines
- Use
zap-baseline.py in CI on every PR since it is non-destructive and catches most common issues passively.
- Run full active scans only on staging, never on production, since active scans send attack payloads.
- Set up authentication before scanning since unauthenticated scans miss vulnerabilities behind login.
- Import OpenAPI specs for API testing to automatically discover endpoints.
- Triage alerts by confidence and risk: address High confidence + High risk first.
- Exclude false positives with scan policy rules rather than ignoring alerts globally.
- Generate both HTML (for humans) and JSON (for automation) reports.
1---2name: owasp-zap3description: OWASP ZAP4---5# OWASP ZAP67## Overview89OWASP ZAP is an open-source web application security scanner that discovers vulnerabilities through spidering, passive analysis, and active attack testing. It detects OWASP Top 10 issues (XSS, SQL injection, CSRF, SSRF, broken access control), integrates with CI/CD via Docker and GitHub Actions, and supports API scanning from OpenAPI specs with configurable scan policies.1011## Instructions1213- When running quick scans in CI, use `zap-baseline.py` which performs passive-only scanning (non-destructive) on every PR and catches approximately 60% of issues without sending attack payloads.14- When running thorough scans on staging, use `zap-full-scan.py` which combines spidering, passive scanning, and active attack testing; never run active scans on production since they send destructive payloads.15- When scanning APIs, use `zap-api-scan.py` with the OpenAPI/Swagger spec to automatically discover and test all endpoints without manual crawling.16- When configuring authentication, set up form-based, script-based, or header-based auth before scanning so ZAP can reach authenticated endpoints that contain the majority of vulnerabilities.17- When integrating with CI/CD, use the Docker image (`ghcr.io/zaproxy/zaproxy`) or GitHub Actions (`zaproxy/action-baseline`), set fail thresholds by alert level, and generate both HTML and JSON reports.18- When triaging results, prioritize by confidence and risk level (High/High first), exclude known false positives with scan policy rules, and ignore Informational alerts in CI.1920## Examples2122### Example 1: Add security scanning to a CI/CD pipeline2324**User request:** "Run OWASP ZAP on every pull request to catch security issues early"2526**Actions:**271. Add a GitHub Action using `zaproxy/action-baseline@v0.12.0` targeting the staging URL282. Configure fail thresholds to break the build on High risk alerts only293. Generate HTML reports as build artifacts for developer review304. Add scan policy exceptions for known false positives3132**Output:** A CI pipeline that runs passive security scanning on every PR with reports and configurable failure thresholds.3334### Example 2: Run a full security audit on a staging environment3536**User request:** "Perform a comprehensive security scan of our web application before launch"3738**Actions:**391. Configure ZAP authentication with the application's login flow402. Run the Ajax Spider for JavaScript-heavy SPA crawling413. Execute a full active scan with High strength on all discovered endpoints424. Generate HTML and JSON reports, triaging alerts by confidence and risk4344**Output:** A comprehensive security audit report with prioritized vulnerabilities and remediation guidance.4546## Guidelines4748- Use `zap-baseline.py` in CI on every PR since it is non-destructive and catches most common issues passively.49- Run full active scans only on staging, never on production, since active scans send attack payloads.50- Set up authentication before scanning since unauthenticated scans miss vulnerabilities behind login.51- Import OpenAPI specs for API testing to automatically discover endpoints.52- Triage alerts by confidence and risk: address High confidence + High risk first.53- Exclude false positives with scan policy rules rather than ignoring alerts globally.54- Generate both HTML (for humans) and JSON (for automation) reports.