isitsecure - Find and fix web-app vulnerabilities in one comman

项目说明

isitsecure

![CI]()
![CodeQL]()
![Release]()
![Python 3.11+]()

AI-powered security scanner for modern web apps. SAST + DAST + LLM code review in a single scan.

Built for de and vibe coders shipping web apps who need to know if their code is secure — without becoming security experts.

Supports: TypeScript/Ja (Next.js, Express, tRPC), Python (Django, FastAPI, Flask), Ja (Spring Boot), Go (net/http, Gin, Echo, chi) — and any HTTP API for DAST.

---

Demo

!isitsecure running a scan — li and a graded report

*isitsecure scan --repo ./your-app — every scanner narrates as it runs, then you get a graded report (and a browseable HTML page) with the fixes.*

Contents

Demo · What It Does

Install · Quick Start · What It Costs

Scan Modes · Scan Depth

What It Scans — DAST · Special DAST · SAST · LLM · Cross-Referencing

Language Support · Output Formats · Suppressing False Positives

Auto-Fix · Security Badge

How We Compare · What It Does NOT Cover

Configuration — API Keys · OOB Callbacks · Authenticated Scanning

CLI Reference · Web UI · MCP (AI coding tools) · Try It on the Test App

Benchmarks · Privacy · Architecture

Scanner Documentation · LSP Setup

Contributing · License · Acknowledgements

What It Does

isitsecure runs 42 rule-based scanners by default — up to 45 with --depth deep — (plus optional AI code review) against your web app in a single command. It combines four approaches that commercial tools sell separately:

SAST (Static Analysis) — scans your source code for without running it

DAST (Dynamic Analysis) — tests your live app by sending real HTTP requests

LLM Code Review — uses AI to find business logic flaws that pattern matchers can't detect

AI Fix Generation — generates code patches with unified diffs for every finding

The unique parts:
1. SAST findings automatically generate targeted DAST tests. Code shows no auth check → scanner sends an unauthenticated request and confirms it's exploitable.
2. AI generates fixes, not just reports. --output fixes produces a Markdown fix plan you can paste into Cursor or Claude Code.

Install

Requirements: Python 3.11+ and git. (isitsecure isn't on PyPI — the isitsecure name there is an unrelated project, so don't pip install it.)

Quick install (recommended)

The installer Python/git, then clones the repo, sets up an isolated en, installs e, and runs first-time setup:

If Python or git are missing, the installer tells you the exact command to install them for your OS and stops cleanly — it ne a half-finished state.

Manual install

Prefer to do it by hand:

pip install -e ".[all]" is the recommended install and enables every scanner. If you want a lighter footprint, the extras are opt-in:

| Install | What works |
|---|---|
| pip install -e . | SAST / code-only scans only (--mode code-only) |
| pip install -e ".[browser]" | Adds DAST / li scanning (requires isitsecure setup to install Chromium) |
| pip install -e ".[llm]" | Adds LLM code review, triage, and AI fixes (requires an API key) |
| pip install -e ".[all]" | E except [taint] (see below) |
| pip install -e ".[taint]" | Deterministic Semgrep taint/injection SAST for JS/TS, Python, Java, and Kotlin. Install separately — semgrep's pinned dependencies don't co-resolve with [all]. The analyzer only needs the semgrep binary on PATH, so pipx install semgrep (or brew) works too; it falls back to LLM-only if absent |

URL/DAST scanning needs the [browser] extra — without it, isitsecure scan <url> exits with a message telling you to install it.

Quick Start

What It Costs

isitsecure is free and open source. The only cost is LLM API tokens for the AI-powered features:

| Scan Mode | API Key Needed | Estimated Cost |
|---|---|---|
| URL-only (DAST without LLM) | No | $0 |
| Code-only (SAST without LLM) | No | $0 |
| Code-only + LLM review | Yes | ~$5–8 |
| Full scan (SAST + DAST + LLM) | Yes | ~$10–15 |

Without an API key, you still get all rule-based scanners — 42 in the default quick depth (16 DAST + 8 special DAST + 18 SAST), or 45 with --depth deep (which adds 3 slower/aggressive DAST scanners). The LLM adds business logic review, semantic rule , injection false-positi (drops heuristic injection FPs by comparing the baseline response), and intelligent triage — things no pattern matcher can do.

Supported LLM pro: Anthropic (Claude), Google (Gemini)

Scan Modes

| Mode | What It Does | Requires |
|---|---|---|
| url-only | DAST scanners against a live URL | Target URL |
| code-only | SAST scanners against source code | GitHub repo URL |
| authenticated | DAST with login credentials (IDOR, cross-user BOLA, RLS, pri escalation) — plus the standard HTTP DAST scanners (injection, CSRF, SSRF, headers, …) now probe behind the login wall against protected endpoints | URL + credentials (add a second account for cross-user tests) |
| full | E: SAST + DAST + authenticated + LLM review + cross-referencing | URL + repo + credentials + API key |
| auto (default) | Detects mode from what you provide | Whatever you give it |

Scan Depth

Orthogonal to mode, --depth trades speed for co:

| Depth | What runs | When to use |
|---|---|---|
| quick (default) | Structural + config checks, error-based injection, a lightweight reflected + POST-body XSS pass, and the snapshot-based scanners (headers, CORS, RLS, source-map, SRI, client-exposure, redirects…). Fast. | E scans — a solid first pass in a fraction of the time. |
| deep | E in quick plus the slow/aggressi: time-based (blind) SQL injection, the full XSS pass (adds static DOM sink analysis), auth-bypass timing, rate-limit bursts, and password-reset flows. | When you want the full arsenal and can wait. |

The scan narrates each phase and every scanner as it runs (with elapsed time), so a longer deep scan shows continuous progress rather than appearing to hang.

Testing the Mutation Surface (--probe-writes)

A path in a Ja bundle carries no HTTP method, so every endpoint is
discovered as a GET. Any scanner that tests POST/PUT then finds nothing
to work on — which leaves **stored XSS, mass assignment, CSRF and SSTI
untested**, because all of them li a state-changing request.

--probe-writes deri endpoints from REST shape: POST to a
collection, PUT to an item.

Measured on OWASP Juice Shop v20.1.1, url-only:

| | without | with --probe-writes |
|---|---|---|
| recall | 22/45 (49%) | 28/45 (62%) |
| CSRF | 0/1 | 1/1 |
| SSTI | 0/1 | 0/1‡ |
| XSS | 1/7 | 4/7 |
| IDOR | 0/6 | 1/6† |
| mass assignment | 0/1 | 1/1 |

‡ SSTI and NoSQL read 0 on the deterministic scanner: their detectors were tightened to differential oracles (product-must-e / operator-must-broaden), which removed ~18 false positives per scan and re the old credits were coincidental. Sound detection of these needs the agentic pentest path.

† --probe-writes IDOR is the mutation path (unauthenticated PUT/PATCH accepted on /api/Products, /api/Hints), not the read path; unauthenticated read-IDOR is 0 because it can't be told from public data without auth — real IDOR needs the authenticated cross-user pass.

It is off by default, and should stay off for anything you do not own.
The scan *writes to the target*: it creates records, and an endpoint that
sends email or charges a card will do so. It also takes roughly 72 minutes
against 27 on that app, since the in doubles.

DELETE is derived and deliberately never sent — a scanner that destroys a
record to prove it could is not worth the finding.

What It Scans

DAST Scanners — Tests Your Live App

19 total — 16 run in the default quick depth; the 3 marked ◆ (slower/aggressi) are added by --depth deep.

| Scanner | What It Finds |
|---|---|
| XSS Scanner | Reflected, POST body, and DOM-based cross-site scripting (quick runs the reflected + POST-body network phases; --depth deep adds the static DOM sink pass) |
| Acti Scanner | SQL injection (error + time-based, incl. SQLAlchemy/sqlite3/psycopg errors), command injection, NoSQL injection, XXE, SSTI — injects query, body, and path parameters |
| CSRF Scanner | Cross-site request forgery on state-changing endpoints |
| Rate Limit Scanner ◆ | Missing or bypassable rate limiting on auth endpoints |
| Session Scanner | Insecure token storage (localStorage), missing cookie flags, long-lived JWTs |
| GraphQL Scanner | Introspection enabled, no depth limits, batch query abuse |
| SSRF Scanner | Ser request forgery (internal IPs, cloud metadata) |
| File Upload Scanner | Unrestricted file types, path tra in filenames |
| Mass Assignment Scanner | Accepting pri fields (role, isAdmin) in request body |
| Security Headers Scanner | Missing CSP, HSTS, X-Frame-Options; ser disclosure |
| CORS Scanner | Wildcard origins, credentials with permissive CORS |
| Open Redirect Scanner | Un redirect parameters |
| Auth Bypass Scanner ◆ | Username enumeration, default credentials, account lockout bypass |
| HTTP Probe Scanner | Method tampering, host header injection, directory listing, .en |
| Password Reset Scanner ◆ | Token leakage in response body, email enumeration, no rate limiting |
| Source Map Scanner | Publicly exposed .map files leaking original source (, not just present) |
| Mixed Content Scanner | http:// resources loaded on an HTTPS page |
| SRI Scanner | External CDN scripts/styles loaded without Subresource Integrity hashes |
| Client Exposure Scanner | Secrets in client JS — Supabase ser keys, internal URLs, unreplaced en |

Special DAST Scanners (8)

| Scanner | What It Finds |
|---|---|
| IDOR Scanner | Insecure direct object references via ID swapping, plus authenticated cross-user (BOLA) testing with two accounts and an anonymous-access false-positi |
| JWT Scanner | Algorithm none bypass, weak secrets, key confusion attacks |
| RLS Deep Scanner | Supabase Row Le bypass via anon key and cross-user queries |
| Pri Escalation Scanner | Admin route access, role self-ele, object-le bypass |
| Authenticated Crawler | Playwright-based login + BFS crawl to disco endpoints |
| Race Condition Scanner | TOCTOU bugs mutation requests |
| DOM XSS Scanner | Playwright-based sink hooking (innerHTML, eval, location.assign) |
| Body Param Fuzzer | Prototype pollution, type confusion, injection via JSON body fields |

SAST Scanners (18) — Analyzes Your Code

| Scanner | What It Finds |
|---|---|
| Semgrep Taint Analyzer | Deterministic source→sink injection for JS/TS, Python, Java, and Kotlin — SQLi, XSS, SSRF, path tra, command injection, SSTI (a reproducible floor beneath the LLM re; needs the [taint] extra, no-ops without the semgrep binary) |
| Git Secret Scanner | API keys, tokens, and credentials in git history (not just HEAD) |
| Route Auth Analyzer | Next.js/Express/Django/FastAPI/Spring routes missing authentication |
| RLS Policy Analyzer | Supabase tables without Row Le enabled |
| Middleware Analyzer | Incomplete middleware co (protects pages but not API routes) |
| Express Middleware Analyzer | Express-specific auth middleware gaps |
| Drizzle Schema Analyzer | Sensiti (isAdmin, role) exposed to mass assignment |
| Prisma Schema Analyzer | Similar checks for Prisma schemas |
| IaC Scanner | Terraform/CloudFormation misconfigurations (public S3, no encryption) |
| Docker Scanner | Running as root, exposed ports, .en into image |
| Shell Script Scanner | Command injection in deploy scripts |
| Dependency Scanner (npm) | Known CVEs in package.json dependencies |
| Python Dependency Scanner | Known CVEs in requirements.txt / pyproject.toml (Django, Flask, FastAPI, PyJWT, etc.) |
| Ja Scanner | Known CVEs in pom.xml / build.gradle (Log4Shell, Spring, Struts, Jackson, etc.) |
| OS Scanner | Real-time C against Google's OSV.de (200K+ vulns, all ecosystems: npm, PyPI, Maven, Gradle, Go, Rust) — no hardcoded CVE list, no API key |
| Firebase Rules Analyzer | Overly permissi/RTDB security rules |
| OpenAPI Scanner | Internal endpoints exposed in API specifications |
| K8s Scanner | Pri containers, no resource limits, hostPath mounts |

LLM-Powered Analysis (requires API key)

| Scanner | What It Finds |
|---|---|
| LLM Code Re | Business logic flaws: missing ownership checks, race conditions in payments, incorrect authorization logic |
| Semantic Rule | Logical errors in RLS policies and Firebase rules (wrong column references, tenant isolation bugs) |
| LLM Business Logic Scanner | Attack planning: price manipulation, double-spend, pri escalation logic |
| LLM Triage Service | Deduplicates findings, assigns priority, generates plain-language owner summary with A–F grade |
| AI Fix Generator | Generates code patches for each finding — paste into Cursor/Claude Code, apply in place with isitsecure fix, or open per-category PRs on a remote repo |

Cross-Referencing + Guided DAST

| Feature | What It Does |
|---|---|
| Lazy-Chunk Bundle Collection | Collects Ja from <link rel=modulepreload/preload/prefetch> as well as <script src> — a code-split SPA ships its routes as <link> chunks, so a script-only sweep sees the shell and none of the API surface |
| OpenAPI/Swagger Discovery | Probes /openapi.json, /swagger.json, /v3/api-docs and parses the spec into testable endpoints — finds attack surface on APIs with no crawlable frontend |
| HTML Form/Link Discovery | Reads <form>/<input>/query-links from ser pages (bounded url-only crawl + inside the authenticated crawler) — finds attack surface on classic MVC apps with no JS API bundle |
| Endpoint Prioritizer + Time Budget | Ranks likely- endpoints first and tests within a per-scanner time budget, so high-risk paths get covered before the clock runs out |
| SAST→DAST Feedback Loop | SAST findings generate targeted DAST tests (6 strategies: auth bypass, IDOR, injection, mass assignment, race condition, RLS bypass) |
| Cross-Referencer | Matches DAST + SAST findings for high-confidence confirmed |
| Import Graph Centrality | Identifies shared utility files imported by many risky routes for LLM review |
| LSP Auth Flow Tracing | Uses TypeScript Language Server to auth middleware is genuinely applied |

Language Support

| Language | Route Mapping | Auth Detection | Dependency Scan | DAST |
|---|---|---|---|---|
| TypeScript/Ja (Next.js, Express, tRPC, GraphQL) | Yes | Yes | Yes (npm) | Yes |
| Python (Django, FastAPI, Flask) | Yes | Yes | Yes (pip) | Yes |
| Ja (Spring Boot) | Yes | Yes | Yes (Maven, Gradle) | Yes |
| Go (net/http, Gin, Echo, chi, gorilla) | Yes | Yes | Yes (go.mod) | Yes |
| Ruby, Rust, PHP, etc. | No | No | No | Yes (DAST works against any HTTP API) |

DAST scanners test live HTTP endpoints regardless of backend language. SAST route mapping, auth detection, and dependency scanning are language-specific. Go auth detection is per-route (router/group middleware, in-handler checks) and the gopls LSP refines it — following a cross-file auth helper to confirm a guard or suppress a false "missing auth". Go module dependencies (go.mod, direct and indirect) are checked against the OSV.de database, like npm/PyPI/Maven.

Output Formats

Suppressing False Positives

A finding you' and accepted (a false positive, or an accepted risk) shouldn't nag you on every scan. Each finding has a stable fingerprint — the same across runs, en (localhost vs. prod), and code edits — shown under each row in the table output (fp <hash>) and in the JSON/SARIF output.

Suppress one by adding its fingerprint to a repo-local .isitsecureignore file, which is committed and re in pull requests:

The .isitsecureignore file is plain text — one fingerprint per line, # comments for context — so suppressions live with your code and are re like any other change. Delete a line to un-suppress.

Suppressed findings are dropped from the findings list, counts, and themes in every output format. (The AI *owner summary* narrative is written during the scan, so it may still mention a finding you suppressed afterward.)

Baseline mode — only show what's new

For an app that already has a backlog of known findings, baseline mode lets you accept the current set once and then, on later scans, see only what's *new* — ideal for a CI gate that should fail on regressions but not on pre-existing debt.

Baselines are keyed per project (repo or target URL) and stored under ~/.isitsecure/baselines/ — machine-local state, unlike the committed .isitsecureignore. Baseline and suppression compose: --baseline shows new, not-suppressed findings. Findings match by the same stable fingerprint, so a baseline survives host/port/query changes and code edits.

In CI: the default ~/.isitsecure/ path is per-machine, so a fresh runner has no baseline and --baseline would show the whole backlog. Point --baseline-file at a path you commit to the repo (or cache between runs) so the gate compares against a shared, baseline:

Re- a fix — is it fixed now?

After you fix something, isitsecure re-checks *specific* findings from a previous scan and tells you fixed — without re-scanning e:

DAST findings are re-probed against the target — the exact endpoint is re-run through the scanner that raised it. To avoid ever *falsely* claiming a fix, a fixed/still-present is only given when a single-endpoint re-probe can faithfully reproduce the finding (endpoint-le like security headers / CORS / CSRF, and parameter-le where the tested parameter is reco). Findings that depend on crawl-deri or multi-request flows (e.g. stored XSS) are reported un — re- those with a full scan.

SAST findings are re-checked against a local --repo via a code-only re-scan.

Omit --fingerprint to re- every finding in the report. Exit codes make it a CI gate: 0 all clear (e fixed), 1 at least one finding still present, 2 inconclusive — something couldn't be (un/error) or a requested fingerprint wasn't in the report. LLM-review findings (which need a model to reproduce) are always un.

(This is the per-finding CLI counterpart to the MCP (scan_id) tool, which instead re-scans e and reports grade mo.)

Auto-Fix: One Command to Fix Your App

fix works two ways depending on what you point it at:

Local path → fixes are applied in place (git-free), with an automatic

backup and a re-scan to confirm each finding is actually resolved.

Remote GitHub URL (with a token) → the repo is cloned, fixed, and the

changes are opened as per-category pull requests — nothing is pushed to
your default branch.

Fix a remote repo → pull requests

Each PR groups related fixes (by category, by default), one commit per finding,
onto a feature branch — never your default branch. --max-prs caps the number
of PRs (default 8); excess low-se categories are batched into a single PR
so nothing is silently dropped. The token is used only for the push + PR and is
ne or logged (env var GITHUB_TOKEN also works).

What the local flow does:
1. Scans your repo with all SAST scanners
2. Backs up the working tree, then for each critical/high finding with a code
location, sends the file to the LLM and writes a fixed
3. Re-scans the fixed code to confirm each finding is resolved
4. Prints a plain-language summary of what was fixed, needs review, or couldn't
be fixed (pass --technical for the git diff / backup-restore details)

Your original files are backed up automatically; the summary tells you how to
review and restore if needed.

Security Badge

Add a security grade badge to your README:

Then add to your README:

The badge shows your grade (A–F) and total finding count, styled like a shields.io badge.

How We Compare

isitsecure is not a replacement for enterprise security platforms. It's designed to be the one tool a solo de or small team needs — combining capabilities that otherwise require 4-5 separate tools.

What only isitsecure does (no other OSS tool)

SAST findings automatically generate targeted DAST tests (closed feedback loop)

LLM reviews business logic (race conditions, price manipulation, ownership checks)

One command scans + generates + applies AI fixes (isitsecure fix)

Cross-references DAST + SAST findings for confirmed

LSP traces auth flows through call chains (TypeScript, Python, Java)

Sound app-logic exploitation — cross-tenant BOLA proven by response-body discrimination (not status codes), JWT alg=none / RS→HS confusion forging, and differential injection oracles (SSTI arithmetic e, NoSQL operator-broadening, OOB SSRF) — so a finding is a *demonstrated* exploit, not a pattern match

Honest, published benchmarking — per-challenge recall against OWASP Juice Shop is measured and reported (see benchmarks/RESULTS.md), with an explicit anti-o discipline (no app names or app-specific routes in the shipped engine). Most OSS scanners publish no recall numbers at all.

Where specialized tools go deeper

| Need | Best specialized tool | How isitsecure compares |
|---|---|---|
| Deep SAST (30+ languages) | Semgrep | We embed Semgrep for deterministic JS/TS, Python, Ja, and Go injection taint (opt-in [taint]) and add LLM review on top; Semgrep's own registry covers far more languages and rules |
| DAST with ad exploitation | OWASP ZAP / Burp Suite | Our DAST is simpler — fewer payloads, no WAF e |
| Secret scanning (800+ patterns) | TruffleHog / Gitleaks | Our git scanner covers common patterns, not exhaustive |
| Container + IaC scanning | Trivy / Checkov | Our IaC/Docker scanners are basic — use Trivy for depth |
| Enterprise compliance (SOC2, PCI) | Snyk / Checkmarx | No compliance mapping (yet) |
| Template-based vuln scanning | Nuclei (28K+ stars) | Not template-based — different approach |
| AI-agent / LLM pentesting | PentestGPT / / cai | Those are research-grade or single-class demos; isitsecure is a maintained, tested (~2,500 tests) and benchmarked product with the same LLM/agentic ideas wired into a deterministic scanner pipeline |

Who should use what

| You are | Use this |
|---|---|
| Solo dev / vibe coder shipping a web app | isitsecure — one tool, one command |
| Team with $25K+ security budget | Snyk + GitHub Ad Security |
| Enterprise with compliance requirements | Checkmarx / |
| Pentester doing deep exploitation | Burp Suite Pro + Nuclei |
| DevOps focused on containers/IaC | Trivy + Checko |

isitsecure works well alongside other tools. Run isitsecure scan for the combined SAST+DAST+LLM view, and use specialized tools where you need deeper co.

What It Does NOT Cover

Inter-procedural taint analysis — The opt-in Semgrep taint layer ([taint]) does intra-file source→sink dataflow for JS/TS, Python, Java, and Kotlin injection; cross-function/cross-file tracking (Semgrep Pro territory) still falls back to LLM reasoning

WAF e — DAST payloads don't include ad bypass techniques

Compliance mapping — No OWASP Top 10, CWE, or PCI-DSS tagging (yet)

Network-le — No port scanning, TLS analysis, or infrastructure enumeration

Mobile apps — Web APIs only

Go/Ruby/Rust SAST — Route mapping not yet implemented (DAST and dependency scanning via OS work)

Configuration

API Keys

Set , .env file, or ~/.isitsecure/config.toml:

OOB Callbacks (Blind Detection)

isitsecure detects blind SSRF, XXE, and injection using out-of-band (OOB) callbacks. By default it uses oob.isitsecure.ai — a free community ser interactsh.

What data is sent? Only the scan *target* makes DNS/HTTP requests to the OOB server. Your source code ne your machine.

Self-host your own:

Disable entirely: Add enabled = false under [oob] in config.

Authenticated Scanning

Cross-user IDOR / BOLA — supply a *second* account and isitsecure logs in as both users and checks whether one user can read or mutate another user's objects (broken object-le). An anonymous-access guard suppresses false positives from endpoints that are simply public.

Frontend-less / plain REST APIs — use --auth-provider token, which logs in against a generic REST login endpoint (auto-discovered, or pass it explicitly with --login-url):

CLI Reference

Web UI

Prefer a GUI? isitsecure launch starts a local web interface backed by the same scan engine — no CLI flags to remember:

The UI provides:

scan configuration — target URL, repo, scan mode, AI provider, and optional login credentials

Live scan progress — a progress bar and a streaming scanner log

Finding browser — filter by se or scanner, plus full-text search, with each finding expandable for e, technical detail, and remediation

Plain-language risk summary — an A–F grade, key risks, and a phased remediation plan

One-click AI fixes — a "Generate Fix" button on any finding produces a unified diff inline (one finding at a time)

Report export — download JSON, or open the self-contained HTML report in a new tab

Scan history — recent scans are remembered locally in your browser

The web ser your LLM API key the same way the CLI does (ANTHROPIC_API_KEY, a .env file, or isitsecure setup), so scans and fixes work without pasting a key into the browser. You can still enter one in the scan form to o it.

Use Inside Your AI Coding Tool (MCP)

isitsecure ships a local MCP server so your
AI coding tool (Cursor, Claude Code, Claude Desktop) can scan your code as a
tool — right in the loop where you're writing it. Nothing is hosted: the tool
spawns isitsecure mcp as a subprocess and talks to it o.

Install the extra, then add one snippet to your tool's MCP config:

Now ask your agent to check your code. It calls the scan tool:

scan(path, min_se="medium") — runs a fast code-only (SAST) scan

on a local repo and returns a security grade, a go/no-go launch ,
se counts, and a trimmed list of findings. Each finding carries a
plain-English explanation (what it is, what an attacker could do, how to fix
it) — guidance the agent can act on, not jargon.

explain(scan_id, finding_id) — after a scan, dig into one finding: its

specific description, the code, and step-by-step remediation. Ask
"explain the SQL injection one" and the agent calls it for you.

fix(scan_id, finding_id) — proposes a patch for one finding (a unified

diff + the fixed file). Your AI tool applies it with its own editor — the MCP
ne files. Ask "fix the SQL injection."

(scan_id) — after you apply fixes, re-scans and reports what

cleared and any grade mo (e.g. F → D). Ask "did that work?"

export(scan_id, format) — render the scan as HTML / SARIF / JSON /

Markdown to share or attach (SARIF feeds GitHub code scanning). Ask "export the
report" — your tool saves the returned file.

scan_url(url) / scan_status(job_id) — DAST-scan a *running* app. DAST

takes minutes, so scan_url returns a job id and scan_status polls it. Ask
"scan my app at

Code-only scans finish in seconds — the natural fit for the AI-coding loop;
scan_url/scan_status add li/DAST scanning (which takes minutes) when
you need it.

The MCP is growing toward the full scan → understand → plan → fix loop. See
docs/mcp.md for the design and roadmap.

Try It on the Test App

The repo includes — an intentionally Next.js + Supabase app with ~50 security issues. All commands below are run from the repo root.

To also run the li (DAST) scanners, start the app first, then scan its URL:

--repo accepts a local directory (scanned in place, including uncommitted changes) or a remote git URL like . See examples/sample-report.json for what a scan produces.

Benchmarks

isitsecure ships a repeatable benchmark harness that scores recall (of the classes an app is known to have, how many we catch) and false positives (findings that must not appear against a hardened build) on public, deliberately- apps.

Measured co — be realistic about what a scanner catches. On OWASP Juice Shop v20.1.1 — a deliberately hard benchmark of 113 challenges — isitsecure detects 49% of the 45 DAST-detectable challenge classes in a url-only scan, scored automatically against the app's own /api/Challenges list. --probe-writes takes that to 62% and an authenticated two-user pass to ~67% — ~76% when authentication and --probe-writes are combined (they find different things: writes buy the stored-XSS and CSRF challenges, authentication buys cross-user object access and the profile-image SSRF — the only sound source of IDOR, since an unauthenticated scan can't tell a leaked record from public data). The url-only pass is deterministic and reproducible in one command (python benchmarks/run_benchmarks.py juiceshop, ~27 min — identical on repeat runs); the authenticated and --probe-writes modes are heavier and vary a little run-to-run (the cross-user IDOR harvest depends on a freshly-registered user having objects to find), so treat ~67–76% as a band, not a fixed figure. It's perfect on SQL injection (7/7, including login/authentication-bypass SQLi — a tautology that logs in where a real credential is rejected), file upload (4/4) and XXE (2/2), and strong on exposed data/secrets, open redirects and misconfiguration. The remaining gaps are rate limiting, SSTI, NoSQL, the stored/header XSS , and two IDOR challenges on routes the scanner doesn't reach (/rest/basket/:id, /rest/products/reviews), plus challenges needing multi-step business-logic exploitation. The ~76% figure needs credentials and --probe-writes (which writes to the target); a no-config url-only scan is the 49%. NoSQL now uses a differential oracle (a Mongo operator must broaden the query vs an exact-match control), which removed the class's old false-positi at the cost of any coincidental recall — it reads 0 on the deterministic scanner, honestly. In other words: a solid automated first pass that catches whole classes of real bugs in one command — not a substitute for a manual pentest. Full per-class breakdown, gaps, and methodology are in benchmarks/RESULTS.md.

Most targets spin the app up in Docker, run a DAST scan, score against a known ground truth, and tear it down (require Docker). The sast-injection target is code-only (no Docker) — it scores the deterministic Semgrep taint layer on a JS/TS + Python + Java + Kotlin injection fixture (46/46 recall, 0 FP) and needs the semgrep binary instead; it's included in the default run. Measured results are tracked in benchmarks/RESULTS.md; see benchmarks/README.md for targets and how scoring works.

Privacy

Rule-based scanning is fully local. SAST scanners clone your repo to a local temp directory and analyze it on your machine — no code leaves your computer unless you enable LLM review.

DAST scanners send HTTP requests to your target URL. Nothing is proxied through external servers.

LLM review sends code to your chosen API provider (Anthropic or Google). To be precise: it sends the full contents of files flagged by the rule-based scanners (capped at ~50 KB per file) — not your entire codebase, but for most source files that is the whole file, not just a snippet. Run --llm none to keep e local.

OOB callbacks only involve your scan target making DNS/HTTP requests to the callback server. Your code is never sent there.

Architecture

See docs/architecture.md for the full pipeline design, including how SAST feeds DAST, how LLM review is prioritized, and how cross-referencing works.

Scanner Documentation

See docs/scanners/ for detailed documentation on every scanner — what it detects, why it matters, real-world breach examples, and how to fix the it finds.

LSP Setup (Optional, Reduces False Positives)

Language servers let the scanner trace auth flows through your code () and suppress false positives — confirming auth middleware is genuinely *applied*, not just imported.

Let isitsecure install them for you:

setup --lsp installs what it can cleanly (Python via pip always; TypeScript via npm if Node is present; Java if a) and prints guidance for anything it can't. It's also offered as a step in the full isitsecure setup. This is optional — scans still work without it using regex-based detection. For manual setup and per-language detail, see docs/lsp-setup.md.

For TypeScript it also pro a private TypeScript 5.x runtime under ~/.isitsecure/lsp — typescript-language-server carries none of its own and won't start without one, and a scan runs against a copy of your project with node_modules stripped, so it can't borrow yours. Your global typescript is ne or changed. To use a specific one instead, set ISITSECURE_TSSER to its lib/tsserver.js. isitsecure setup --check prints the runtime a scan will use.

Contributing

isitsecure is built on protocols and the strategy pattern. Adding a new scanner is straightforward:

1. Implement DASTScannerProtocol or CodeScannerProtocol
2. Add it to the scanner list in isitsecure/engine/factory.py
3. Add tests under tests/

Set up a de with pip install -e ".[all,dev]", then run the suite with pytest. Issues and pull requests welcome at github.com/jaurakunal/isitsecure.

License

Apache 2.0 — see LICENSE.

Acknowledgements

interactsh by ProjectDiscovery for the OOB callback protocol

Playwright for browser automation in authenticated crawling and DOM XSS detection

项目信息

开发语言：Python

Star 数：43

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Find and fix web-app vulnerabilities in one command — SAST + DAST + AI, for devs who aren't security experts.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。