Security & vulnerability disclosure

Last updated: 2026-06-05

We welcome reports of security vulnerabilities. This policy explains what is in scope, what is out of scope, how to report, what safe-harbour we offer, and what to expect in response. It is aligned with ISO/IEC 29147:2018 (vulnerability disclosure), the Coordinated Vulnerability Disclosure principles, and the CSIRT.PT guidance for the Portuguese national CSIRT.

Reporting channel

Email [email protected] with a clear technical write-up. The same address is published in our security.txt file at /.well-known/security.txt. For encrypted reporting, request our PGP public key in your first email.

Scope

In scope:

• The outletpicks.com production site and all subdomains we own.
• The Telegram bot integration we publish.
• Email sending pipelines from @outletpicks.com.
• The mobile-optimised web app and any future native apps published by us.
• Public APIs documented at /api/openapi.json when published.

Out of scope:

• Third-party domains we link to (Amazon, iHerb, etc.).
• Findings limited to outdated TLS cipher suites without a working exploit.
• Self-XSS where the user must paste payload into their own console.
• Best-practice notes without a security impact (e.g. lack of a non-essential security header where a CSP already mitigates the underlying risk).
• Reports requiring physical access to a victim’s device.
• Social-engineering attacks against staff.
• Rate-limiting denial-of-service tests against our production infrastructure (use staging or coordinate first).

Safe-harbour terms

We will not take legal action against good-faith security researchers who:

• Stay within the scope above.
• Do not access, modify, or delete any data beyond what is necessary to demonstrate the vulnerability.
• Do not exfiltrate user data or hold it after disclosure.
• Do not run denial-of-service attacks.
• Do not socially engineer staff, users, or partners.
• Give us reasonable time to remediate before publicly disclosing details.
• Use a test account they created, not someone else’s account.

Safe-harbour is informal and does not override legal obligations to third parties whose systems may be implicated. When in doubt, ask first.

What to include in a report

• Affected URL and HTTP method.
• Reproduction steps, ideally as a working PoC (curl command, video, or screenshot).
• Impact assessment (what data or function is exposed).
• Suggested CVSS v3.1 score.
• Your handle if you want public credit, or “anonymous”.

Response SLAs

• Acknowledgement within 24 hours of receipt.
• Initial triage within 3 working days.
• Fix or mitigation timeline depending on severity:
  • Critical (remote code execution, full account takeover, mass PII exposure): patched within 7 days.
  • High (single-account compromise, stored XSS, IDOR): patched within 30 days.
  • Medium (limited info disclosure, CSRF on non-sensitive endpoints): patched within 60 days.
  • Low (best-practice gaps with marginal impact): batched into the next release cycle.

Bounty

We do not currently run a paid bug bounty. Outstanding research is acknowledged in the public changelog and on the recognised-reporters page below. We may, at our discretion, offer a thank-you of swag, free premium features (if/when introduced), or a charitable donation in your name.

Recognised reporters

We list, with their permission, the names of researchers whose reports have led to a material security fix. To opt out of public credit, mark your report “Anonymous”.

Public disclosure

We support coordinated disclosure. Once a fix is deployed and any affected users are notified, you are welcome to publish technical details. Where a CVE is appropriate we’ll work with MITRE or the relevant CNA.

Related policies

See our privacy policy Section 12 on security measures, the terms Section 6 on prohibited use, and the contact page for general support.