Skip to content

Documentation

Everything you need to secure your AI-built projects

Scanning

Getting Started

Scanning

BoringSec offers one Security Audit for deployed websites. Start with a URL, receive the base report quickly, then let authorized background engines add verified-owner depth without blocking the report.

One report, progressive results
Fresh reports surface technical evidence, explicit verification notes, prioritized fixes, and developer handoff exports. The base report becomes usable first. Eligible deeper engines continue independently and update that same Security Audit when their results are ready.
Deep engines require a verified owner
Public and anonymous scans run applicable base modules only. Injection, XSS, and Ports, plus the external Nuclei, ZAP, and Medusa engines, 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.

The Security Audit entry point

Free preview

Website Security Audit

Paste a deployed website URL to run applicable checks for headers, TLS, DNS, bundle exposure, injection risk, and other observable security signals.

Verified-owner scans can add Injection, XSS, Ports, and external Nuclei, ZAP, and Medusa engines

Typical scan time: Base results usually within 60 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 ownership verification, an owner can configure a supported access method for a deeper, owner-authorized assessment. Access is limited to the verified domain and is used only for that assessment. You can set an expiration time and revoke access sooner from the domain settings.

Authorization

Verified owner or authorized team administrator

Execution

Used only during an isolated, owner-authorized assessment

Retention

Expires automatically and can be removed sooner

Disclosure

Access values are not shown in reports or public interfaces

Authenticated does not mean fully assessed
Coverage depends on the access you provide and the parts of the application reachable during the assessment. Unassessed checks stay marked as partial or unavailable. Some identity, authorization, and business-logic controls require dedicated authorized or manual testing.

Access values are protected server-side, are not returned through public report surfaces, and are removed automatically when they expire. Revoking access prevents it from being used by future assessments.

How to run a scan

Option 1: Dashboard (no API key needed)

Go to New Scan, paste a deployed website URL, 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 Injection, XSS, Ports, 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 Injection, XSS, Ports, 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.

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.