ci: enable OWASP ZAP baseline DAST scan (#46)

[Parzivalart3mis]

Closes #46 (partially — see Follow-ups).

Background

The zap-scan.yml skeleton has existed on the owasp-zap branch since Sep 2025 but has never run successfully. Two reasons:

1. Its target was the placeholder https://your-qa-url.example.com (a reserved example domain).
2. It triggered on push/pull_request to a qa branch, which does not exist in this repo — so once merged to main it would never fire.

Credit where it's due: @umssyed created the original workflow skeleton (his commits are preserved in this branch's history), and @Mdnadeem13 validated the whole approach in May by running ZAP against test-saayam.netlify.app and confirming real findings. This PR finishes that work rather than restarting it.

What this changes

Before	After
target: your-qa-url.example.com	https://test-saayam.netlify.app (overridable via workflow_dispatch)
push: [qa, owasp-zap] — never fires	pull_request: [main] + nightly cron + manual dispatch
action-full-scan with -a (active attack)	action-baseline with -I (passive)
fail_action: true	fail_action: false (non-blocking for now)
Reports generated but unreachable	Uploaded as artifacts, 30-day retention
No permissions: block	permissions: contents: read + concurrency
ZAP files a GitHub issue per run	allow_issue_writing: false

Also adds .zap/rules.tsv, which suppresses four informational rules (timestamp disclosure, cache-control, "modern web app", non-storable content) while deliberately keeping the security-header and CSP rules active — those are the actual findings this issue exists to surface. The file documents that intent inline so the signal doesn't get "cleaned up" later.

Scope deviation, flagged deliberately

The issue asks for reports stored in S3. This PR uses GitHub Actions artifacts instead.

S3 requires AWS credentials, which have been the standing blocker on this and several other issues. Artifacts give 30-day retention, need no access provisioning, and match the pattern already used in playwright-tests.yml. If S3 is a hard requirement, it can be added as a follow-up once credentials exist — this seemed better than leaving DAST unimplemented for another cycle.

Verification

• .zap/rules.tsv confirmed tab-separated (ZAP silently ignores space-separated rules files)
• Workflow YAML parses; triggers and steps resolve correctly
• Target confirmed live (HTTP/2 200)
• Current response headers on the target:

MISSING : content-security-policy
MISSING : x-frame-options
MISSING : x-content-type-options
MISSING : permissions-policy
MISSING : referrer-policy
PRESENT : strict-transport-security

Five of six missing, which corroborates @Mdnadeem13's May findings and confirms the scan will report real issues. It's also why this lands non-blocking: with fail_action: true, every PR would fail immediately.

Not verified: I could not execute a real ZAP scan locally (no Docker daemon available). The workflow's end-to-end behaviour is unconfirmed until it runs in Actions. Suggest a workflow_dispatch run right after merge, before relying on the nightly schedule.

Open question

The issue says "QA environment"; @Mdnadeem13 validated against test-saayam.netlify.app, described as the test environment. If QA and test are distinct here, the target value should change — it's a one-line edit, and workflow_dispatch accepts an override in the meantime. @anisha2207 @umssyed, could you confirm?

Follow-ups (not in this PR)

1. Active scanning — switching to action-full-scan with -a sends real attack payloads. Wants explicit sign-off from @anisha2207 / @umssyed first, especially as the endpoint is Netlify-hosted and their ToS apply.
2. Flip to blocking once the baseline is clean.
3. S3 archival, if still required, once AWS credentials are available.

🤖 Generated with Claude Code