//Legal

Security & responsible disclosure

Last updated 18 August 2026. How the scanner behaves, what we store, and how to report a bug in Flare. Machine-readable contact: https://flarehq.dev/.well-known/security.txt.

Report a vulnerability in Flare

If you find a security issue in flarehq.dev, the scan API, the dashboard, or our client libraries, tell us before you tell Twitter. Use the contact form with topic “security”, and include steps to reproduce. Do not attach live secrets belonging to other people.

We aim to acknowledge within 48 hours, keep you updated, and credit you on this page once it is fixed if you want the credit. Please do not access other users’ data, degrade the service, or run destructive tests. Good-faith research that follows this policy is welcome; we will not pursue a legal claim against you for that research.

In scope

  • flarehq.dev and the hosted API (scan, auth, billing webhooks, Guard ingest).
  • Authentication and authorisation bugs that expose another user’s scans or connections.
  • Injection, SSRF against our infrastructure, or a way to read secrets we store.

Out of scope

  • Findings in a third-party app you scanned with Flare. Report those to the app’s owner, not as a Flare vuln.
  • Rate-limit complaints, missing security headers on marketing pages, or SPF on a domain we do not use for mail.
  • Social engineering of the founder, or physical security.
  • Automated scanner output with no working proof.

There is no bug bounty program yet. We will still take a real report seriously and credit you if you want that.

How the free scan behaves

The public URL scan is read-only. It requests the same HTML, JavaScript, headers, and well-known paths that any visitor’s browser would, plus public DNS lookups (SPF/DMARC). It does not log in, submit forms, upload files, modify data, or send exploit payloads.

Live-key verification makes one read-only identity request to the provider that issued a credential. It is not a login to the customer’s app.

Connected (deep) scans

Connected audits, live database schema and RLS, GitHub/GitLab repo analysis, are Pro features you turn on from the dashboard. Connections are least-privilege, read-only, and revocable. Separately, the free flare-deep repository scanner runs on your own machine or in your CI and sends us nothing unless you point it at the hosted API.

Scanning apps you don’t own

You must have permission to scan a target. If Flare surfaces a real exposure on an app that isn’t yours, disclose it to the developer before anything is published. The homepage feed, when it is live, shows only a category of finding, never a name, a URL, or evidence.

Acceptable use is in the Terms. In short: no load testing, no enumerating strangers’ hosts, no reconnaissance against critical infrastructure you have no relationship with. We rate-limit per network and globally. A one-way hash of the network address is used for that limit; we do not store the address.

What we keep, and for how long

  • Anonymous scans are not stored as account history. One free scan per website per network; a second scan of the same host asks you to go Pro (or scan a different site).
  • Signed-in free tracks one site. Continuous history, rescans, and monitoring are Pro. Deleting a scan or the account removes the record and its findings.
  • Shared reports are only reachable if you explicitly publish them, and can be unpublished.
  • We never store your source code, your database rows, or the full value of any credential we detect, only a redacted fragment sufficient to identify it.

If a scan of your app exists and you want it removed, tell us from an address at that domain and we’ll delete it. You don’t need an account to ask. Full retention rules are in the Privacy Policy.

security.txt

RFC 9116 file: https://flarehq.dev/.well-known/security.txt. Contact points at this disclosure process. Preferred language is English.