Skip to content

Documentation

Everything you need to secure your AI-built projects

Scanning

Getting Started

Scanning

BoringSec offers 4 scan modes: URL, GitHub repo, code files, and full project payloads. Each mode runs the relevant security analyzers and feeds into reports, exports, and AI-ready remediation.

What changed in the deeper product
Fresh reports now surface richer technical details, explicit verification notes, developer handoff exports, and broader scanner coverage across website, GitHub, code, and project analysis paths.
Deep engines require a verified owner
Public and anonymous scans run applicable base modules only. Nuclei, ZAP, and Medusa are admitted only for a signed-in, non-anonymous scan of a domain owned by that user or team and marked VERIFIED. A requested engine without authorization is authorization_required; a module that was not requested is not_requested. On eligible scans, the isolated jobs run independently in the background, never block the base report, and update the same report when results are ready. A failed job remains visible without discarding other results.

Four scan modes

Free+

URL Scan

Paste any URL to run applicable base checks for headers, SSL, bundle exposure, and other observable security signals.

Applicable base web checks; verified-owner scans may add background engines

Typical scan time: Base results usually within 60 seconds

Pro+

GitHub Repo Scan

Paste a GitHub repo link — we review for committed secrets, vulnerable dependencies, auth flaws, unsafe code, and operational gaps.

Code patterns + review signals + dependency audit

Typical scan time: ~30 seconds

Pro+

Code Scan

Upload or paste code files — we detect hardcoded secrets, unsafe patterns, and configuration issues without needing a deployed URL.

30+ detection patterns

Typical scan time: ~5 seconds

Business+

Project Scan

Send a project payload through the API when you want multi-file or generated-code review without exposing a public URL.

Cross-file patterns + repo-level review metadata

Typical scan time: ~10 seconds

How scoring works

An assessable security scan produces a Security Score and, when enough AI-stack coverage is available, a Boring Score. Insufficient coverage is shown as unavailable or provisional, never invented.

Security Score (0-100)

Weighted average across all scanner categories. Headers, SSL, and injection have the highest weights. If a CRITICAL vulnerability is found, the score is capped at 30.

A++ (100)Flawless
A+ (90-99)Excellent
A (80-89)Good
B (70-79)Fair
C (60-69)Needs work
D (40-59)Poor
F (0-39)Critical

Boring Score (0-100)

Specifically weighted for AI-generated code vulnerabilities. Secrets and database security count for 65% of this score.

Secrets (bundle + hardcoded)40%
Database (Supabase RLS, Firebase)25%
Auth & Injection20%
Headers, SSL, CORS15%

What we detect

Core scanners run in parallel, and newer report surfaces preserve richer coverage, trust semantics, and export paths. Each issue includes severity, detailed context, and a fix recommendation.

Secret Detection

Stripe, Supabase, OpenAI, Anthropic, AWS, GitHub tokens — 11 provider-specific patterns in source code and JS bundles

Supabase Security

Live RLS testing with anon key, service_role key exposure, overpermissive policies

Firebase Security

Open Firestore/RTDB rules, publicly writable storage buckets

Auth & Middleware

Clerk publicRoutes wildcard, missing middleware, JWT in localStorage, OAuth email linking

Security Headers

CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Server header

SSL/TLS

Certificate validity, weak protocols (TLS 1.0/1.1), cipher strength, expiry warnings

DNS Security

SPF, DKIM, DMARC records — protects against email spoofing

Injection & XSS

SQL injection, command injection, template injection, reflected and DOM-based XSS, SSRF

Exposed Files

.git, .env, backups, source maps, admin panels, debug endpoints — 40+ paths checked

Cookies

HttpOnly, Secure, SameSite attributes on session cookies

CORS

Wildcard origins, credentials with wildcard — cross-origin abuse vectors

Vulnerable Dependencies

20+ JS and 7 Python packages with known CVEs (lodash, jsonwebtoken, axios, etc.)

Stripe & Payments

Webhook signature verification, hardcoded keys, missing CSRF on payment flows

GDPR

Cookie consent, privacy policy presence, third-party trackers without consent

Platform Detection

Identifies Lovable, Bolt, v0, Vercel, Netlify, Firebase hosting — tailors checks accordingly

WAF Detection

Identifies web application firewalls (Cloudflare, Vercel, AWS WAF)

Severity levels

CRITICALImmediate exploitation risk. Exposed secrets, open databases, active injection vectors. Fix before anything else.
HIGHSignificant vulnerability that should be fixed within days. Missing auth, weak crypto, XSS vectors.
MEDIUMSecurity weakness that should be addressed. Missing headers, insecure cookie flags, deprecated dependencies.
LOWMinor issue or best practice recommendation. Informational headers, outdated but not vulnerable deps.
INFOInformational finding. Technology detection, configuration details, no action required.

Authenticated scanning

After DNS ownership verification, open the domain's Settings tab to configure a bearer token, custom header, session cookie, or bounded login form. A form login is a single same-origin HTTPS URL-encoded POST with fixed username and password field names: custom scripts, arbitrary extra fields, credentials in URLs, and cross-origin redirects are not supported. The credential is scoped to the verified hostname/origin, but ZAP may send it to same-host paths discovered by its spider. The test path proves protected access and the form path establishes a session; neither is a crawl path allowlist.

Authorization

Signed-in owner, team owner, or team admin on a VERIFIED domain

Execution

Ephemeral header available only inside the isolated OWASP ZAP job

Retention

User-selected 7, 30, or 90 days, plus immediate manual deletion

Disclosure

Credential values never appear in API responses, reports, jobs, logs, or audit metadata

Authenticated does not mean fully assessed
Authenticated ZAP evidence can cover paths visible to one configured session. The current single-credential flow does not assess MFA, account enumeration, cross-account IDOR or other two-identity authorization, transaction-specific CSRF, password policy, or JWT lifecycle. Those require dedicated multi-identity or manual testing and are never reported as a clean pass from this profile.

Credentials are encrypted with domain-bound AES-256-GCM. Production requires a server-only AUTHENTICATED_SCAN_ENCRYPTION_KEY. For rotation, deploy the new current key and retain the former value temporarily as AUTHENTICATED_SCAN_PREVIOUS_ENCRYPTION_KEY. New profiles use the current key; old profiles remain decryptable during their selected retention window. Remove the previous key after the maximum 90-day window or after all profiles have been replaced.

How to run a scan

Option 1: Dashboard (no API key needed)

Go to New Scan, paste a URL or GitHub repo link, and click Scan. Base results usually appear within 60 seconds. Public and anonymous URL scans stop at applicable base modules. An eligible signed-in scan of an owned, verified domain can continue with Nuclei, ZAP, and Medusa in the background. Free tier: 1 preview scan. Paid plans include monthly scan quotas (Care 4 · Pro 10 · Business 50).

Option 2: REST API

Use the REST API to scan programmatically. Great for CI/CD pipelines, agent workflows, automated testing, and custom integrations.

curl
curl -X POST https://www.boringsec.com/api/v1/scan \
  -H "$(printf 'Authorization: Bearer %s' "$BORINGSEC_API_KEY")" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-app.com", "async": true}'

URL scan creation returns HTTP 202 with polling links; fetch the base result only after status becomes COMPLETED. For an eligible verified-owner scan, keep polling while deepScan.active is true to receive Nuclei, ZAP, and Medusa updates. Public, anonymous, unowned, or unverified targets do not start those engines; their recorded state is authorization_required when requested, or not_requested when not requested. For coding workflows, also use /api/v1/scan/code and /api/v1/scan/project.

Option 3: Claude Code MCP

Set up the BoringSec MCP plugin and ask Claude: "Scan https://myapp.com for security issues". Claude runs the scan and formats the results for you. The preferred setup now uses one-time device authorization rather than manually copying an API key.

Ready to scan?

Free preview scan. No credit card. See exactly what AI left exposed.