Skip to content
BoringSec

Methodology · evidence before claims

A security report that shows what was proven — and what was not.

BoringSec combines bounded URL modules with independent deep engines. Every result keeps its evidence, coverage state, and authorization boundary visible, so a missing scanner can never masquerade as a clean result.

Run a security scanExplore a sample report

Published URL coverage

17 + 6

Evidence-led
17 pre-verification URL modules
Bounded public checks build the first report before ownership is verified.
6 verified-owner heavy scanners
Injection, XSS, Ports, Nuclei, ZAP, and Medusa settle independently. 3 are external engines.

A module may use several target-specific probes, so not every branch runs against every site. We count published modules instead of advertising a theoretical check total.

What actually runs

One progressive report. Six verified-owner heavy scanners.

The inventory below comes from the same public capability registry used by the product. Conditional engines are labeled as conditional instead of being sold as universal coverage.

Registry 2026-07-18.1 · reviewed 2026-07-18 · machine-readable JSON

7 modules

First useful evidence

Fast web posture

Headers, transport, DNS, exposure, cookies, CORS, and platform signals run first so the report can surface common launch risks quickly.

  • Security HeadersEvaluates browser security policy and server-disclosure headers.4 public check families
    • Content Security Policybs.headers.csp
    • Strict Transport Securitybs.headers.hsts
    • Browser isolation and content controlsbs.headers.browser-controls
    • Server technology disclosurebs.headers.disclosure
  • SSL/TLSChecks certificate identity, validity, protocol posture, and HTTPS redirection.4 public check families
    • Certificate identity and validitybs.ssl.certificate
    • TLS protocol supportbs.ssl.protocols
    • Cipher posturebs.ssl.ciphers
    • HTTP to HTTPS redirectbs.ssl.redirect
  • DNS & Email AuthenticationReviews public DNS, mail-authentication, and transport-policy records.3 public check families
    • SPF, DKIM, and DMARCbs.dns.email-auth
    • CAA, MTA-STS, TLS reporting, and DANEbs.dns.transport-policy
    • DNSSEC, MX, and nameserversbs.dns.delegation
  • ExposureChecks a bounded set of commonly exposed public artifacts and administrative surfaces.4 public check families
    • Public secret and configuration artifactsbs.exposure.secrets
    • Public backup and data artifactsbs.exposure.backups
    • Administrative and diagnostic surfacesbs.exposure.admin
    • Public source maps and development artifactsbs.exposure.source-maps
  • CookiesReviews observable cookie security attributes without retaining cookie values.4 public check families
    • Secure transport attributebs.cookies.secure
    • HttpOnly attributebs.cookies.httponly
    • SameSite policybs.cookies.samesite
    • Prefix and domain scopebs.cookies.scope
  • CORSTests how the public endpoint responds to bounded cross-origin requests.3 public check families
    • Allowed origin policybs.cors.origin-policy
    • Credentialed cross-origin accessbs.cors.credentials
    • Cross-origin methods and exposed headersbs.cors.methods
  • Platform DetectionIdentifies hosting and application-platform signals used to tailor remediation.2 public check families
    • Hosting and deployment platformbs.platform.hosting
    • Application platformbs.platform.application
13 modules

Pre-verification and owner-gated

In-process application surface

These modules inspect public behavior, shipped artifacts, framework clues, backend exposure, privacy signals, reputation, and client-side threats. Injection, XSS, and Ports remain owner-gated. The other applicable modules contribute before verification.

  • VirusTotalLooks up existing multi-vendor reputation evidence for the normalized origin and hostname while suppressing single-vendor noise.2 public check families
    • Multi-vendor malicious and suspicious verdictsbs.virustotal.verdicts
    • Community reputationbs.virustotal.community
  • Technology & Live CVEsFingerprints observable components and enriches supported versions with live advisories.3 public check families
    • Observable technology fingerprintbs.technology.fingerprint
    • Version disclosurebs.technology.version-disclosure
    • Version-linked vulnerability advisoriesbs.technology.advisories
  • InjectionUses bounded differential probes for externally observable injection behavior.3 public check families
    • Database error differentialbs.injection.sql-error
    • Boolean response differentialbs.injection.sql-boolean
    • Command-processing signalbs.injection.command-signal
  • XSSLooks for bounded reflected and client-side script-injection signals.3 public check families
    • Context-sensitive input reflectionbs.xss.reflection
    • Client-side source and sink signalsbs.xss.dom-flow
    • Dynamic code execution usagebs.xss.dynamic-code
  • SubdomainsEnumerates a bounded public set and checks reachable hosts for takeover and transport signals.3 public check families
    • Public subdomain inventorybs.subdomains.inventory
    • Dangling service bindingbs.subdomains.takeover
    • HTTPS reachabilitybs.subdomains.transport
  • WAFIdentifies observable web-application firewall signals and bounded response behavior.2 public check families
    • WAF or edge-protection fingerprintbs.waf.fingerprint
    • Bounded protection responsebs.waf.coverage
  • PortsChecks a bounded set of high-risk public TCP services.3 public check families
    • Public datastore servicesbs.ports.datastores
    • Public remote administration servicesbs.ports.remote-admin
    • Legacy cleartext servicesbs.ports.legacy
  • GDPR / ePrivacy & Legal SurfaceReviews observable consent, privacy, legal, and basic accessibility signals.5 public check families
    • Public privacy notice contentbs.gdpr.privacy-notice
    • Observable third-party transfer signalsbs.gdpr.transfer-signals
    • Basic document accessibility signalsbs.gdpr.accessibility
  • Bundle SecretsChecks publicly shipped scripts and configuration artifacts for credential-like material.3 public check families
    • Credential-like material in shipped assetsbs.bundle-secrets.credentials
    • Sensitive service configurationbs.bundle-secrets.service-config
    • Private-key materialbs.bundle-secrets.private-keys
  • SupabaseValidates observable Supabase configuration and bounded unauthenticated data access.3 public check families
    • Privileged key exposurebs.supabase.privileged-key
    • Unauthenticated table accessbs.supabase.rls
    • Public storage enumerationbs.supabase.storage
  • FirebaseTests observable Firebase services for bounded unauthenticated read access.4 public check families
    • Firebase configuration exposure contextbs.firebase.config
    • Realtime Database read accessbs.firebase.database
    • Firestore read accessbs.firebase.firestore
    • Storage read accessbs.firebase.storage
  • ReputationChecks supported public threat and blocklist sources.2 public check families
    • Safe browsing reputationbs.reputation.safe-browsing
    • Supported domain blocklistsbs.reputation.blocklists
  • Client-Side ThreatsReviews publicly shipped client code and resources for high-risk behavior signals.5 public check families
    • Payment-skimmer behavior signalsbs.client-threats.skimmer
    • Cryptomining behavior signalsbs.client-threats.miner
    • Suspicious redirect behaviorbs.client-threats.redirect
    • Third-party resource integritybs.client-threats.sri
    • Mixed active or passive contentbs.client-threats.mixed-content
3 conditional engines

Independent deep coverage

Verified-owner background engines

Nuclei, OWASP ZAP, and Medusa are the three external engines. They share the verified-owner boundary below with the in-process Injection, XSS, and Ports scanners.

  • NucleiRuns a curated, non-destructive template set on an isolated verified-owner worker.1 public check family
    • Curated vulnerability templatesbs.nuclei.curated-templates
  • OWASP ZAPRuns bounded baseline or explicitly configured API analysis on an isolated verified-owner worker.2 public check families
    • Passive baseline alertsbs.zap.baseline
    • Configured API surface analysisbs.zap.configured-api
  • MedusaAnalyzes code-like artifacts that the verified site publicly ships.2 public check families
    • Public client-code security rulesbs.medusa.code-rules
    • Public source-map analysisbs.medusa.source-maps

Connected repository scan

Conditional · read access required

The published GitHub repository module can inspect authorized source for secrets, dependency and framework-risk patterns that a public URL cannot expose. It is a separate surface and is never implied by a URL-only report.

  • Committed secret and credential patternsbs.github-repository.secrets
  • Dependency vulnerability signalsbs.github-repository.dependencies
  • Framework security patternsbs.github-repository.frameworks
  • Container and CI hardeningbs.github-repository.pipeline

Revision history

Changes stay attached to a published registry version.

Reports link to stable module and check-family IDs. This history is rendered from the same typed registry as the public JSON contract, so documentation changes cannot silently create a separate methodology timeline.

  1. 2026-07-18.1Current

    Moved every bounded lightweight module into the pre-verification report and limited domain verification to heavy scanners.

    • Made exposure, CORS, technology, subdomains, WAF, Supabase, and Firebase available before domain verification.
    • Restricted the verified-owner execution gate to Injection, XSS, Ports, Nuclei, OWASP ZAP, and Medusa.
    • Kept partial and unavailable evidence states distinct instead of promoting lightweight scanner output to a verified result in report displays or exports.
  2. 2026-07-15.1

    Aligned public evidence, authorization, privacy, and repository-collection boundaries with the implemented scanners.

    • Published deterministic anchors for every module and public check family.
    • Linked report categories and explicitly mapped finding families to those anchors.
    • Documented cross-origin bundle collection with per-hop SSRF validation and sanitized source locations that never expose reusable credentials.
    • Made verified domain ownership an explicit prerequisite for active Supabase table and storage probes.
    • Documented the bounded, non-executing GitHub codeload snapshot path, honest partial and unavailable states, and authenticated API fallback for private or out-of-contract repositories when a connected grant is available.
    • Restricted VirusTotal to privacy-minimized origin and hostname lookups, documented the provider boundary, and disabled full URL submission until a separate durable verified-owner consent receipt exists.
  3. 2026-07-14.1

    Initial typed public methodology registry.

    • Published URL, verified-owner background, and connected-repository module boundaries.
    • Published stable check-family IDs, evidence semantics, scoring rules, and safety limits.

Ownership boundary

Domain verification is an authorization control, not a badge.

The bounded lightweight report—including Supabase and Firebase checks—runs before domain verification. Injection, XSS, Ports, Nuclei, ZAP, and Medusa are the heavy scanners. Before running those probes or creating an independent job, the server re-checks that the scan is signed in, is not public or crawler-generated, belongs to the account, and still points to a verified domain.

Verify a domain
  1. 1

    Sign in and add the domain

    Verified-owner active probes are never authorized by an anonymous or crawler scan. The domain must belong to the signed-in account.

  2. 2

    Publish the DNS TXT token

    Copy the unique token from the domain page into the domain DNS. BoringSec does not accept a screenshot or a client-side claim as proof.

  3. 3

    Verify from the domain page

    The server resolves the live TXT records and marks the domain verified only when the stored token is present.

  4. 4

    Watch each engine settle

    The newest eligible signed-in Security scan is queued automatically. All six heavy scanner jobs then report queued, running, retrying, completed, or failed independently.

Report truth states

Coverage gaps stay visible. They do not become reassuring copy.

A module’s state answers a different question from a vulnerability’s severity. The report keeps both so you can distinguish “no issue found” from “not verified.”

Verified finding

Concrete evidence supports the reported outcome. Only verified weighted categories receive score credit.

Partial coverage

Useful evidence was collected, but one or more bounded stages could not be verified. The category is withheld from a clean pass and from weighted score credit.

Queued or running

An authorized background engine has not completed. The base report remains available, while this engine stays unscored until its result is persisted.

Unavailable or not applicable

The category could not produce reliable evidence, was not authorized, or was not applicable. The report records the reason and excludes that missing coverage from a verified pass.

Safety and limits

Useful automation without pretending to be a pentest.

The product is deliberately bounded. That protects targets, keeps results reproducible, and makes every limitation explicit.

  • Public and anonymous scans receive the bounded lightweight report but cannot authorize Injection, XSS, Ports, or the isolated background engines.
  • The default Nuclei policy excludes DoS, brute-force, intrusive, and fuzz tags. Outbound targets pass public-address and exact-host controls.
  • ZAP defaults to bounded baseline analysis. Optional authenticated or API paths require explicit server-side configuration and the same verified-origin boundary.
  • Medusa collects a bounded set of publicly shipped scripts, source maps, and configuration artifacts. It never executes customer source code.
  • Unavailable, timed-out, authorization-required, and not-applicable modules are not converted into “passed” checks.
  • Automated, bounded, non-destructive public-surface testing with reproducible evidence and prioritized remediation guidance.

See the methodology in a real report

Start with evidence you can verify and fixes you can ship.

Run the broad bounded audit now. Verify ownership only when you want Injection, XSS, Ports, independent deep engines, and the ongoing domain workflow.

Scan a siteView sample report