Trust center lite

Security posture without enterprise theater.

A concise reference for teams reviewing how BoringSec handles scan data, secrets, retention, subprocessors, and responsible scanning boundaries.

Security contact

Report security concerns to hello@boringsec.com with enough detail to reproduce the issue. We prioritize exploitable issues, data exposure, auth bypasses, and billing/security boundary bugs.

Data handling summary

BoringSec stores scan targets, scan results, findings, account data, billing state, and integration settings needed to provide reports, monitoring, alerts, and support. Secrets are treated as server-only and must not be logged or exposed in client bundles.

Report retention

Anonymous report access expires after 30 days and request network metadata is removed at expiry. Owned and paid report history remains while needed for the account, purchase, or monitoring relationship, subject to deletion rights and narrow legal/security exceptions.

Secrets redaction

Reports should identify risky exposure without printing full secrets. Environment templates, examples, audit logs, screenshots, and client-side code should stay redacted unless a value is intentionally public.

Subprocessors

The production stack is self-hosted on an EU Hetzner VPS. Stripe processes billing; Google and GitHub process data only when their optional OAuth, advertising-consent, or repository features are used. External AI remains disabled unless explicitly configured and disclosed.

Responsible scanning

BoringSec uses bounded, non-destructive checks. Public URL fetches and outbound webhooks use SSRF defenses, redirects are constrained where applicable, and scanner failures are represented with availability/confidence notes.

Legal and authentication coverage

Every row distinguishes implemented evidence, conditional coverage, and work that is outside automated assessment. “Not observed” never means “non-compliant.”

Privacy, consent, and data rights signals

implemented

Surface: Initial URL response plus bounded same-origin privacy-policy fetches

Evidence: 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

Surface: Initial HTML plus a bounded same-origin fetch of an explicitly linked terms page

Evidence: 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

Surface: Public response headers, cookies, shipped JavaScript, login links, entry-page forms, and at most one bounded same-origin login-page fetch

Evidence: 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

Surface: Verified-owner domains with an explicitly configured, expiring credential profile

Evidence: 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

Surface: User-authorized repository or archive scan

Evidence: 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

Surface: Outside automated product scope

Evidence: 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.

Retention matrix

These are the normal production windows and minimization rules. A deletion request can shorten them unless a legal, billing, fraud, or security obligation applies.

Data	Window	Deletion / minimization
Anonymous URL scan report and request network metadata	Public report access expires after 30 days.	IP address, user agent, country, and city are removed when access expires. The anonymous scan record is deleted after a further 7-day cleanup grace period.
Signed-in domains, scans, findings, monitoring history, and paid reports	Retained while needed to provide the account, purchase, report history, or monitoring relationship; no shorter fixed automatic window is promised.	The owner can delete a domain/account or request erasure. Related product data is deleted or anonymized unless a legal or security obligation requires limited retention.
Authenticated-scan bearer token, cookie, custom header, or bounded form-login username/password	The owner selects 7, 30, or 90 days; the profile expires automatically.	Credentials are encrypted with authenticated encryption, never returned by the API, loaded only inside the isolated scan boundary, and can be revoked earlier. Form credentials are exchanged for a bounded session cookie inside that boundary.
Connected repository content and repository access credentials	Source is fetched for the authorized scan; findings and scan metadata remain with the report history.	Repository credentials stay server-side and can be revoked. Full source content is not intentionally copied into public reports; evidence is minimized and secrets are masked.
Authenticated repository ZIP, bounded file manifest, and redacted static-analysis findings	The raw ZIP is deleted immediately after a completed, failed, or quarantined result, with a 24-hour cleanup fallback. The manifest and findings expire after 30 days.	The owner can delete the scan sooner. Raw source stays in a dedicated non-public bucket; source files are never returned by the API, and secret-bearing evidence is redacted before result storage.
Raw product analytics sessions	90 days.	Raw analytics sessions older than the window are deleted by the scheduled retention job.
Audit-log IP addresses and user agents	Direct IP and routine user-agent detail are minimized after 90 days; routine cron heartbeat rows are deleted after 30 days.	IPv4 is reduced to /24 and IPv6 to /48. User agents are removed from non-security audit rows.
Closed support and inbound-reply conversations	24 months after the last message.	Closed conversations older than the window are deleted by the scheduled retention job.
Billing and transaction records	For the tax, accounting, dispute, and fraud-prevention period required by applicable law and payment operations.	BoringSec stores provider identifiers and purchase state, not full payment-card data.

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.

Need a security review packet?

Enterprise customers can request procurement/security review support, custom volume, white-label reports, and dedicated onboarding.

Contact security