Security and Responsible Disclosure

Applies to: Users and researchers who report a suspected security weakness in the Platform
Summary of changes: Initial vulnerability-reporting framework. Contact and response commitments are not yet approved.
Contact: [SECURITY EMAIL — must be verified before publication]

Draft for review. No verified public vulnerability-disclosure address or security.txt was found in the audit. Do not publish a contact placeholder as a working channel. Safe-harbor wording requires qualified counsel and security approval.

In plain words

If you think you found a security issue, stop testing as soon as you can describe it safely and tell us through the verified channel listed here once it is published. Do not access, change, copy or delete anyone else’s data; disrupt the service; or test Codes, accounts or systems you do not own. This draft is not a promise of legal immunity.

1. Reporting a vulnerability

Send a concise report to [SECURITY EMAIL] or use [SECURE REPORTING METHOD]. Include:

• the affected Platform page or component;
• steps to reproduce using only an account and data you control;
• the potential impact and any safe proof-of-concept;
• the date/time and environment; and
• a way to contact you, if you want a response.

Do not include passwords, secret keys, full payment credentials, other users’ personal data or a dump of production records. Redact tokens and use a safe test account. Do not attach executable files unless the security team requests them through an approved channel.

2. Testing boundaries

Unless you have written authorization, do not:

1. access, alter, retain or disclose data belonging to another person or Company;
2. use social engineering, phishing, physical intrusion or denial-of-service testing;
3. run automated tests that degrade service or evade rate limits;
4. create, consume, copy or publish real product Codes to demonstrate an issue;
5. install malware, persist access, or change or delete data; or
6. publicly disclose the issue before coordinating with the security contact.

If you accidentally encounter personal or confidential information, stop, do not inspect further, do not save or share it, and report only the minimum details needed to locate the issue.

3. What happens after a report

The security team should acknowledge, assess, prioritize, remediate or otherwise respond to a report and coordinate disclosure where appropriate. The team must publish realistic response targets only after it has an owner and operational capacity: [ACKNOWLEDGEMENT TARGET] · [STATUS UPDATE TARGET] · [COORDINATED DISCLOSURE PERIOD]. No response time is promised by this draft.

Do not expect a reward unless an approved program explicitly states eligibility and conditions. Report handling may require limited processing of your contact details and technical evidence; see the Privacy Policy.

4. Safe-harbor wording

Any assurance about good-faith testing, authorization, civil or criminal action, or safe harbor must be drafted by qualified counsel for [COUNTRY/LAW] and approved by the security owner: [LAWYER REVIEW: jurisdiction-specific safe-harbor statement and exclusions]. Until then, do not imply immunity from law, a customer contract or a third-party claim.

5. Contact and complaints

Security contact: [SECURITY EMAIL]
Alternate urgent contact: [SECURITY CONTACT METHOD]
Privacy contact: [DPO EMAIL]
Operator: [COMPANY LEGAL NAME] · Address: [ADDRESS]

How to complain

If you cannot use the reporting channel or believe a report was mishandled, contact [SECURITY ESCALATION CONTACT]. For privacy concerns, contact [DPO EMAIL]. These details must be verified and staffed before publication.

Proposed security.txt fields

Do not place this template at /.well-known/security.txt until all values are verified and HTTPS access is confirmed:

Contact: mailto:[SECURITY EMAIL]
Preferred-Languages: en
Policy: https://[DOMAIN]/security
Expires: [RFC 3339 UTC DATE]

Change log