Pre-deploy Security Scan (MCP)

The same Opsis MCP server that runs pre-deploy launch checks can also run an OWASP Top 10 security scan before you ship. Your coding agent (Claude Code, Cursor, Windsurf) opens your running app in a real local Chromium and, as it crawls, checks each page for common security problems — missing security headers, insecure cookies, mixed content, accidentally-exposed files, reflected input, outdated front-end libraries, and leaked error pages.

How a scan flows

The scan is confirmation-first by design — built to walk a non-programmer through it safely. Your agent reads the guide, then confirms with you in plain language before anything sensitive runs:

1. Your agent calls opsis_security_scan_guide to learn the calm, step-by-step journey — it never scans until you say yes.
2. It calls opsis_check_environment (read-only) to see whether the local Chrome/Chromium browser is installed. On your machine this is a one-time ~150MB download you approve; on Opsis' servers it's already there.
3. It confirms the running app URL, asks whether the app needs a login, and — only with your okay — runs opsis_run_security_scan with confirm: true.
4. Opsis opens up to a few pages in the browser, runs the checks, and (when your project is configured) saves the redacted findings to the dashboard with a friendly, non-jargon summary.

Setup

The security scan uses the same MCP server and project key as launch checks — if you've already set up pre-deploy checks, you're ready. The key (opk_…) and install snippets live on your project's Before Ship tab, under “Run the check on your machine with your coding agent”. Make sure Chromium is available:

npx playwright install chromium

Then start your dev, preview, or staging server and ask your agent, e.g.:

Run an Opsis pre-deploy security scan against http://localhost:3000.

The three tools

What it checks

Findings are mapped to the OWASP Top 10 (2021) categories (A01–A10). The browser observes each page's response headers, cookies, and content passively as it loads. You can also opt in to active probes (activeProbes: true) — a small set of GET-only, same-origin, SSRF-guarded requests that look for accidentally-public files (like a leaked .env) and a single benign reflected-input marker. Active probes only read; they never submit forms or change anything, and they're off by default. A safety cap limits how many pages are scanned (maxPages, default 12).

Every finding is honest about confidence

Each finding carries a state so you always know how sure Opsis is — and whether a check even ran:

• confirmed — directly observed (e.g. a missing header).
• likely — a strong heuristic signal, not proven.
• info — an informational / good-practice note, not a vulnerability.
• skipped — the check was intentionally not run; the report says why.
• needs_auth — only evaluable behind a login (run an authenticated scan).

Only confirmed and likely findings count toward the “needs attention” headline. Each finding also has a severity (critical → info), a plain-language explanation, and a concrete fix.

Scanning behind a login

Privacy

• The browser runs on your machine. The Opsis MCP server never reads your codebase.
• Only redacted findings and honest run metadata (pages analyzed, checks run, auth mode, duration) are sent to the dashboard. Console/network/page errors and URLs are redacted and capped before they leave your machine.
• The browser recording (video + screenshots) is captured locally, then uploaded to your dashboard after the report is saved so you can review it. If the upload fails, the findings are still saved and Opsis tells you honestly — it never hides a failure.
• The opk_ key is scoped to one project's launch-report API. It cannot read your PostHog data, findings, or anything else in the dashboard.

Related

• Pre-deploy Checks (MCP) — the functional launch-check flow that shares this MCP server.
• Privacy & Redaction — what is redacted before anything leaves the trust boundary.