Security

Responsible Disclosure Policy

Last updated: April 15, 2026

User safety is a top priority. Researchers reporting vulnerabilities responsibly are treated as partners.

How to report

Email [email protected] with a subject starting with [SECURITY].

Include: vulnerability description, detailed reproduction steps, proof of concept (PoC), estimated impact, and (if possible) a suggested fix.

For sensitive disclosures, use the PGP key published at /.well-known/pgp-key.txt.

Timeline (Safe Harbor)

We acknowledge reports within 48 hours and provide an initial assessment within 5 business days.

We commit to remediating valid vulnerabilities within 90 days before any public disclosure. For critical issues under active exploitation, we may request additional time with transparent communication.

Researchers acting in good faith under this policy will not face legal action from us regarding the report.

Rewards

We do NOT currently run a paid bug bounty program.

As recognition we offer: public credit in the Hall of Fame (/security/hall-of-fame), mention in release notes, and swag for high-impact reports.

A formal bounty program is planned as the product matures. Recurring researchers will get priority.

In-scope assets

  • api.firmo90.com (Node.js / Express backend)
  • admin.firmo90.com (Admin dashboard)
  • firmo90.com and www.firmo90.com (Marketing site)
  • Android app (com.firmo90.app) and iOS app once published
  • Production *.firmo90.com subdomains

Out-of-scope

  • Denial of Service (DDoS, volumetric, application-layer)
  • Social engineering targeting employees, contractors, or users
  • Physical access to offices, devices, or data centers
  • Spam, phishing, or abuse of public forms
  • Third-party dependency CVEs without an exploitable PoC against Firmo90
  • Automated scanner output (Nessus, OWASP ZAP, etc.) without manual validation
  • Email configuration issues (SPF/DKIM/DMARC) without an effective spoofing PoC
  • Best-practice issues without demonstrated impact (low-criticality missing headers)
  • Brute-force / credential stuffing without proving rate-limit bypass

Testing rules

  • Do NOT access more user data than strictly needed to confirm the issue
  • Do NOT modify, delete, or exfiltrate production data
  • Do NOT run load or stress tests that affect real users
  • Use test accounts you create yourself whenever possible
  • Stop testing once the vulnerability is confirmed and report immediately

What NOT to do

Public disclosure before remediation (public zero-day) voids safe harbor.

Extortion attempts in exchange for non-disclosure are treated as crimes under applicable law.

Contact

[email protected] — technical vulnerabilities

[email protected] — privacy / LGPD matters (Art. 41)