Skip to content

Documentation

Everything you need to secure your AI-built projects

Overview

Overview

Security that fits how you already build.

BoringSec catches the security gaps AI tools leave behind — hardcoded secrets, broken RLS, missing auth, unsafe patterns — and hands you copy-paste fixes for Cursor, Lovable, Bolt, and every other AI coding tool.

Why BoringSec

Built specifically for AI-generated code (Cursor, Lovable, v0, Bolt)
Applicable base modules publish first; eligible deep engines update verified-owner reports when ready
Fix prompts optimized per platform — copy, paste, done
Supabase RLS live testing — actually queries your DB with the anon key
Detects Clerk middleware gaps, Stripe webhook bypass, Firebase rules
Free preview scan — see your score and issue names, no credit card
REST API for CI/CD — fail builds on critical vulnerabilities
Claude Code MCP plugin — security checks as you code

Quick start — scan via API

Queue with one curl command, then poll the returned status link. No SDK needed.

curl
JOB=$(curl -sS -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}')

echo "$JOB" | jq '.scan | {id, status, links}'

The endpoint returns HTTP 202. Poll scan.links.status every five seconds, then fetch scan.links.result. An API key authenticates the request, but Nuclei, ZAP, and Medusa are admitted only for a non-anonymous scan of a domain owned by the signed-in user or team and marked VERIFIED.

Get your API key from Settings → API Keys (Pro plan). All requests use Authorization: Bearer bsk_your_key.

Developer guides

What BoringSec scans

The public registry currently contains 20 base URL modules plus 3 verified-owner background engines. Applicable base modules publish the report first. Public and anonymous scans run those base modules only. Nuclei, ZAP, and Medusa require a signed-in, non-anonymous scan of a domain owned by that user or team and marked VERIFIED. A requested engine without that authorization is reported as authorization_required; an engine that was not requested is not_requested. Eligible jobs run independently in the background and update the same report when ready without blocking or retracting the base result.

Secret detection

AI tools often hardcode API keys straight into your source. We detect 11 provider-specific patterns: Supabase, Stripe, OpenAI, Anthropic, AWS, GitHub, Firebase, and more.

Finds the Stripe key your Cursor session left in the bundle.

Scan for secrets

Supabase & Firebase security

We actually query your Supabase instance with the anon key to test whether RLS is enforced, audit Firebase Security Rules, and detect exposed service_role keys.

Uses live, evidence-backed RLS checks where the target permits them.

Test your RLS

Auth & middleware gaps

Clerk publicRoutes wildcards, missing Next.js middleware, JWTs in localStorage, OAuth email-linking flaws — eight auth-specific patterns.

Catches the "everything is public by default" mistake.

Check your auth

Injection, XSS & SSRF

SQL, command and template injection, DOM-based and reflected XSS, SSRF via user-controlled URLs, and mass assignment with Prisma.

Finds the attack vectors AI-generated code commonly introduces.

Fix prompts (42+ templates)

Every issue comes with a copy-paste fix prompt optimized for your specific AI tool — Cursor, Lovable, Bolt, Claude Code, v0, Windsurf or Replit.

Fix a critical vulnerability in 2 minutes, not 2 hours.

Browse templates

.cursorrules / AGENTS.md generator

Generate stack-specific security rules that make every future AI coding session security-aware — Next.js + Supabase, Firebase, Clerk and Stripe stacks.

Prevention beats detection. Stop vulnerabilities before AI writes them.

Generate rules

Checks at a glance

These are examples inside the 20 base URL modules, not an aggregate promise that every target runs the same number of atomic probes. The exact branches depend on the target response, detected stack, authorization, and upstream availability. See the scanner reference for the evidence contract.

Security headers

7 checks

SSL / TLS

5 checks

DNS (SPF/DKIM/DMARC)

4 checks

Exposed files

4 checks

Cookies

3 checks

CORS

2 checks

XSS

2 checks

SQL injection

3 checks

Supabase RLS

3 checks

Firebase rules

2 checks

Hardcoded secrets

11 patterns

Unsafe code

15 patterns

Vulnerable deps

20+ packages

GDPR

3 checks

Bundle secrets

2 checks

WAF detection

1 check

Privacy, consent, and data rights signals

implemented

Initial URL response plus bounded same-origin privacy-policy fetches. Consent controls, first-response cookies, trackers, controller/DPO language, legal basis, recipients, retention, deletion/export rights, complaints, transfers, and safeguards are recorded with matched evidence.

Limit: JavaScript-rendered controls and later browser interactions are not executed in this pass; missing evidence is partial or not observed, not proof of non-compliance.

Terms, WCAG basics, and public notices

implemented

Initial HTML plus a bounded same-origin fetch of an explicitly linked terms page. Terms availability, licensing/IP language, document language, page title, image alt attributes, main landmark, form-control names, button names, copyright notice, and licensing/attribution links are recorded independently.

Limit: This is not a full WCAG audit, legal opinion, intellectual-property clearance, or proof that a document is enforceable in every jurisdiction.

Public authentication signals

implemented

Public response headers, cookies, shipped JavaScript, login links, entry-page forms, and at most one bounded same-origin login-page fetch. Session-cookie flags, client-side token storage signals, exposed auth artifacts, CORS, login-surface applicability, and static anti-CSRF token signals are assessed when observable.

Limit: MFA, enumeration, IDOR, server-side CSRF enforcement, and JWT claim/lifetime checks remain not assessed by a public scan. A public scan does not log in, create accounts, submit state-changing forms, modify tokens, or replay object identifiers.

Authenticated application surface

conditional

Verified-owner domains with an explicitly configured, expiring credential profile. The credential is attached only inside the isolated ZAP deep-scan boundary and is scoped to the verified hostname/origin. The test path validates access and the form-login path establishes a bounded session; neither is a ZAP path allowlist, so ZAP may spider other same-host paths. The public report exposes authentication status, never credential names or values.

Limit: The current single-credential ZAP flow has no scenario DSL or second identity and does not support MFA, enumeration, IDOR/tenant-isolation, or transaction-authorization verification; those controls remain not assessed and require dedicated authorized testing or manual review. CSRF or JWT findings may surface opportunistically, but their absence is not a pass.

Repository auth and authorization patterns

conditional

User-authorized repository or archive scan. Selected OAuth linking, token storage, cookie configuration, JWT verification, middleware coverage, secret, dependency, and webhook patterns are checked against the submitted source.

Limit: Source patterns are evidence leads, not runtime proof. Business-object ownership and role policy still require dedicated authorized tests or manual review.

Formal legal or accessibility certification

not assessed

Outside automated product scope. BoringSec links each automated observation to its evidence and applicable reference.

Limit: The report is not legal advice, a penetration-test attestation, or certification of GDPR, CCPA, WCAG, SOC 2, ISO 27001, or licensing compliance.

AI data boundary

External model processing is disabled unless a server operator explicitly configures an AI provider for the relevant feature. Deterministic scanning, scoring, and reports continue when AI is disabled. AI generation runs only when an AI analysis or guidance feature is explicitly requested and available. It is not required to calculate the Security Score.

For scan analysis, BoringSec sends the domain, score, grade, optional Boring/vibe score, critical/high/total issue counts, and up to 10 findings per affected category with title, severity, and a description capped at 200 characters. For paid MCP guidance, it sends the tool name, report timestamp, provenance/status/headline, finding/severity/confidence/verification counts, analysis profile, engine version, and up to 5 top findings with id, title, severity, confidence, verification status, category, optional location, recommendation, up to 4 evidence strings, and up to 6 evidence-trace kind/message entries; it also sends up to 4 next actions and 4 minimized remediation-plan steps.

The analysis payload does not intentionally include account passwords, scan credentials, cookie values, full page bodies, raw source archives, payment-card data, or full secret values.

If an external provider is enabled later, the minimized request crosses to that provider and its API/business data-handling terms, security controls, abuse-monitoring retention, and transfer safeguards apply. The Privacy Policy and subprocessor disclosure must be updated before that change is enabled in production.

Ready to ship secure?

Start with a free scan. No account required. See exactly what AI left exposed.

API base URL

https://www.boringsec.com/api/v1

Authenticate with Authorization: Bearer bsk_your_key. Rate limits: Pro 100/hr, Team 1000/hr, Enterprise 5000/hr. See pricing for plan details.