Security Policy

Updated on 21st April 2026

How to report a vulnerability

If you believe you have found a security issue affecting Timepath, please email security@timepath.co. A valid report must include:

• The affected URL, endpoint, or component.
• A clear, reproducible proof-of-concept (steps, request/response, or short video) demonstrating real impact.
• A description of the security impact in concrete terms.
• Your name or handle if you wish to be credited in an internal acknowledgment (see below).

No bug bounty program — no monetary rewards

Timepath does not operate a bug bounty program. We do not offer monetary rewards, gifts, swag, or public acknowledgments in exchange for unsolicited vulnerability reports. Submitting a report does not create any entitlement to compensation.

Emails requesting payment, "compensation", "a small token", or threatening public disclosure unless a payment is made will be ignored and may be reported to the relevant email provider's abuse contact and, where applicable, law enforcement.

What we will not acknowledge

The following report types are out of scope and will not receive a reply:

• Missing or "weak" HTTP security headers without a demonstrated exploit (e.g. CSP, Permissions-Policy, X-* headers).
• SPF, DKIM, DMARC, or MX configuration findings without a working spoofing proof-of-concept against our production domain.
• Automated scanner output (Nessus, Burp, Nuclei, etc.) submitted without manual verification.
• Self-XSS, clickjacking on pages with no sensitive actions, or theoretical CSRF on logged-out endpoints.
• Rate-limiting, brute-force, or denial-of-service issues.
• Findings on third-party services or domains not owned by Timepath B.V.
• Reports stating that security.txt or a specific header is missing, now that this page exists.

Safe harbor for good-faith research

If you act in good faith, follow this policy, limit your testing to your own account or test data, avoid accessing or modifying other users' data, do not degrade our services, and give us reasonable time to address an issue before public disclosure, we will not pursue legal action against you.

This safe harbor does not extend to extortion, data exfiltration, destructive testing, or disclosure of user data.

Response expectations

We aim to acknowledge valid, in-scope reports within five working days. We do not commit to a fixed triage, patch, or disclosure timeline: security work is prioritised against real user impact. Follow-up "have you fixed it yet?" emails do not accelerate triage.

Machine-readable policy

Our RFC 9116 security.txt file is published at /.well-known/security.txt.

Contact