Last updated: 2026-06-12

Security & Vulnerability Disclosure Policy

We take security seriously. Trepeat processes broker credentials, trade data, and payment information, so we welcome reports from good-faith security researchers. This page describes how to report a vulnerability and what you can expect from us in return.

Contact

Email security@trepeat.com. If you need to send sensitive material encrypted, request our PGP key in your first message and we will reply with the public key before you send the report.

This page is the official "Policy" URL referenced in our /.well-known/security.txt record (RFC 9116).

In Scope

The production web application at app.trepeat.com.
The marketing site at trepeat.com.
Production API endpoints (AWS Lambda functions reachable from the production app).
Authentication, session, and authorisation logic.
Row-level security policies on the production Supabase database (demonstrated only via your own account data).
Stripe webhook handling and other webhook endpoints exposed by the production app.

Out of Scope

Denial-of-service, volumetric load testing, or any attack designed to degrade availability.
Social engineering of Trepeat staff, contractors, customers, or vendors (including phishing, smishing, vishing, or pretexting).
Physical attacks against offices, employees, hardware, or data-centre facilities of any sub-processor.
Findings from automated scanners without a working proof-of-concept (e.g. raw SSL Labs / Qualys output).
Reports about missing security headers, cookie flags, or TLS configuration without a demonstrated security impact.
Open-redirect, clickjacking, or self-XSS reports without a meaningful exploitation path.
Vulnerabilities in third-party dependencies that we do not deploy in a vulnerable configuration.
Issues affecting only outdated browsers, jailbroken devices, or unsupported platforms.
Staging, preview, and demo environments unless explicitly invited.
Email spoofing reports related to SPF / DKIM / DMARC unless they enable account takeover.

Rules of Engagement

When testing, please:

Test only against accounts you own or accounts whose owner has given you explicit written permission.
Stop and report immediately if you encounter another user's data — do not download, copy, or retain it.
Avoid actions that degrade service for other users.
Avoid privacy violations, destruction of data, and interruption of trading flows.
Do not attempt to access, modify, or destroy data belonging to other customers.
Do not exploit a vulnerability beyond the minimum required to confirm its presence.

What to Expect

Acknowledgement — We aim to acknowledge valid reports promptly.
Triage decision (in-scope vs. out-of-scope, severity) — we aim to triage reports promptly after acknowledgement.
Remediation timeline — depends on severity. We commit to keeping you updated and to credit you publicly (if you wish) once the fix has shipped.

Safe Harbour

If you make a good-faith effort to comply with this policy when researching and reporting a vulnerability, we will:

Consider your activity authorised under our Terms of Service and applicable computer-misuse laws (such as the computer-misuse provisions of the Maltese Criminal Code and equivalent laws in your jurisdiction), to the extent it is within our power to grant that authorisation.
Not pursue or support legal action against you for the research.
Work with you to understand and resolve the issue quickly.

If a third party (for example, a sub-processor or an upstream platform) initiates legal action against you for activity that complied with this policy, we will make the third party aware of your authorisation.

Bug Bounty

We do not currently operate a paid bug-bounty programme. We may introduce a coordinated vulnerability-disclosure programme in the future. In the meantime, we publicly credit researchers (with their permission) for valid reports.

Reporting Tips

Reports are easier to triage when they include:

A clear summary of the vulnerability and its security impact.
Step-by-step reproduction instructions.
A working proof-of-concept (script, request, video).
The affected URL, endpoint, function, or component.
Your suggested remediation, if any.
Whether you would like public credit on the fix advisory.

Changes to This Policy

We may update this Policy from time to time. When we make a material change we will revise the "Last updated" date above and notify registered users by email before the change takes effect. Continued use of Trepeat after the effective date constitutes acceptance of the revised Policy.

Thank You

We appreciate every researcher who takes the time to make Trepeat safer for our users. If you have a question about this policy before starting research, email security@trepeat.com and we will reply.