Legal

Security & vulnerability disclosure

Last updated: 25 May 2026

We take security seriously and welcome reports from independent researchers. This page explains what is in scope, how to reach us, what to include in a report, and what you can expect from us in return. A machine-readable version of the contact details is also published at /.well-known/security.txt per RFC 9116.

In scope

The following surfaces are in scope for vulnerability reports:

  • The production web application at nlit.app and any of its subdomains we operate (including app.nlit.app and the marketing site).
  • The production API at api.nlit.app.
  • The official nlit Figma plugin published on the Figma Community.
  • The official nlit CLI (nlit, installed via Homebrew or downloaded from our release page).

Out of scope

The following are not in scope. Please report these directly to the responsible party — we cannot act on issues we don't control.

  • Third-party services we use as sub-processors: Stripe, Anthropic, Vercel, Fly.io, Neon, and Cloudflare. See our sub-processors page for the full list.
  • Denial-of-service, volumetric, or resource-exhaustion attacks. Do not run these against our infrastructure.
  • Social engineering of nlit staff, contractors, or customers (phishing, vishing, pretexting, physical-access attempts).
  • Reports generated solely by automated scanners with no demonstrated impact (e.g. missing low-severity HTTP headers on static assets, banner grabs, theoretical TLS configuration nits).
  • Vulnerabilities in software end-of-lifed by the upstream vendor — we'll log them, but won't treat them as a disclosure case.

How to report

Email security@nlit.app with a description of the issue. This inbox is monitored by the engineering team; please don't use the general support address for security reports — it slows things down and can expose details to the wrong audience.

We do not yet publish a PGP public key. If you need to send sensitive content encrypted, mention this in your initial (unencrypted) email — including only the bare minimum to establish context — and we will set up an encrypted channel before you send details. A published key will be added to this page when available.

What to include

To help us reproduce and triage quickly, please include:

  • A clear description of the vulnerability and the affected surface (URL, endpoint, plugin version, CLI version).
  • Step-by-step reproduction instructions, including any payloads, accounts, or preconditions needed.
  • The commit SHA, release tag, or approximate date of the build you tested against, if known.
  • An impact assessment — what an attacker could do with this, and the privilege/role required to exploit it.
  • Whether you want public acknowledgement (see Recognition below) and the name you'd like to be credited under.
  • Any screenshots, video, or proof-of-concept code that helps demonstrate the issue.

What you can expect from us

  • Acknowledgement within 48 hours of receipt — a human-written reply, not an autoresponder.
  • A status update within 5 business days, including our preliminary severity assessment and whether we're able to reproduce the issue.
  • Regular progress updates until the issue is fixed or formally declined.
  • Coordinated disclosure timeline: we ask researchers to hold public disclosure for 90 daysfrom initial report for non-critical issues. Critical, actively exploited issues are exempt from the window — disclose immediately if customers are at imminent risk and we'll work in parallel.
  • A post-fix write-up, if you'd like one, that you can publish under your name.

Safe harbour

We will not pursue legal action against researchers who, acting in good faith, follow this policy. Specifically, we won't treat the following as a violation of our Terms of Service:

  • Testing against your own test accounts, or accounts you have explicit permission from the owner to test.
  • Accessing only the minimum data necessary to demonstrate the vulnerability, and not exfiltrating, modifying, or retaining customer data beyond what is needed for the report.
  • Stopping testing and notifying us as soon as you encounter customer data you did not expect to see.
  • Reporting the issue privately to security@nlit.app rather than publishing or disclosing it elsewhere first.

Activities that are notcovered by this safe harbour include: accessing or modifying data belonging to other customers, denial-of-service attacks, social engineering of staff or users, and any action that violates applicable law. If you're unsure whether a planned test is in scope, email us before you run it.

Recognition

We do not currently run a paid bug bounty programme. If you would like public recognition for a valid report, we'll list your name (or chosen handle) on a public acknowledgements page once the issue is fixed, with your consent. Reports submitted anonymously remain anonymous.

Also see our Privacy Policy, sub-processors page, and Terms of Service.