Peerdom Vulnerability Disclosure Policy (VDP) - Security

Peerdom AG welcomes feedback from security researchers and the general public to help improve our security. If you believe you have discovered a vulnerability, privacy issue, exposed data, or other security issues in any of our assets, we want to hear from you. This policy outlines steps for reporting vulnerabilities to us, what we expect, what you can expect from us.

Our commitments

When working with us, according to this policy, you can expect us to:

• Respond to your report promptly, and work with you to understand and validate your report;
• Strive to keep you informed about the progress of a vulnerability as it is processed;
• Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints; and
• Extend Safe Harbor for your vulnerability research that is related to this policy.

Our expectations

In participating in our vulnerability disclosure program in good faith, we ask that you:

• Play by the rules, including following this policy and any other relevant agreements. If there is any inconsistency between this policy and any other applicable terms, the terms of this policy will prevail;
• Report any vulnerability you’ve discovered promptly;
• We ask for a working PoC or at least a proof/sample, that the reported vulnerability can actually be exploited;
• Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience;
• Use only the Official Channels to discuss vulnerability information with us;
• Provide us a reasonable amount of time (at least 90 days from the initial report) to resolve the issue before you disclose it publicly;
• Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope;
• If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept (PoC); and cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information;
• You should only interact with test accounts you own or with explicit permission from the account holder; and
• Do not engage in extortion.

Official channels

Please report security issues via security@peerdom.org, providing all relevant information. The more details you provide, the easier it will be for us to triage and fix the issue.

Systems in scope

This policy applies to any digital assets owned, operated, or maintained by Peerdom AG.

Out of scope

Assets or other equipment not owned by parties participating in this policy. Vulnerabilities discovered or suspected in out-of-scope systems should be reported to the appropriate vendor or applicable authority. Submissions that relate to the following vulnerabilities will be considered out-of-scope and will not be eligible for rewards:

• Hyperlink injection on emails
• Rate limiting
• Best practices concerns (we require evidence of a security vulnerability)
• Vulnerabilities only affecting users of outdated or unpatched browsers and platforms
• Race conditions that don’t compromise the security of any user or Peerdom
• Reports about theoretical damage without a real risk
• The output of automated scanners or language models without explanation, or findings the reporter has not personally validated against a live Peerdom system
• CSRF with no security implications (like Login/logout/unauthenticated CSRF)
• Broken links
• Missing cookie flags on non-security sensitive cookies
• Attacks requiring physical access to a user’s device
• Missing security headers not related to a security vulnerability
• Reports of insecure SSL/TLS ciphers unless you have a working proof of concept
• Banner grabbing issues to figure out the stack we use or software version disclosure
• Open ports without a vulnerability
• Password and account recovery policies, such as reset link expiration or password complexity
• Disclosure of known public files or directories, (e.g. robots.txt)
• Reports of spam
• Username/email address enumeration
• Presence of autocomplete attribute on web forms
• Email and DNS security records — including DNSSEC, DMARC, DANE, MTA-STS, TLS-RPT and BIMI — whether missing or set to a permissive policy (e.g. a DMARC policy of p=none)
• HSTS or CSP headers
• Host header injection unless you can show how a third-party can exploit it
• Reflected File Download (RFD)
• EXIF information not stripped from uploaded images
• DoS vulnerabilities based on submitting a large payload in an input field and triggering a 500 error
• Using product features like invitation/signup/forgot-password to deliver messages to any email address
• Unrestricted file upload without a clear attack scenario or PoC
• Inadequate reports containing only screenshots or recordings without a clear description and reproduction path
• Reports from employees or contracted freelancers who have previously worked at Peerdom AG
• Markdown-related, non-XSS HTML injection (e.g. link tags)
• Reports of accounts that can be accessed using credentials sourced from third-party breaches, infostealer logs, paste sites, or other external sources (i.e., credential stuffing / OAT-008). Reuse of credentials by end users against unrelated services is not a vulnerability in Peerdom.
• Clickjacking, framing or UI redressing without a demonstrated, security-relevant state-changing action
• Tabnabbing, or a missing rel="noopener" / rel="noreferrer" attribute on outbound links
• Sessions that remain valid after a password change, an email address change, or the deletion of the external identity used to register, without a demonstrated path to account takeover
• CSV, TSV or spreadsheet formula injection in exported files, where exploitation depends on the recipient overriding their spreadsheet application’s own warning about formulas or external content
• Findings already reported by another researcher, already known to us, or already tracked in our internal backlog at the time your report reaches us. We consider the first complete and reproducible report of an issue.
• Open redirects on our marketing website (peerdom.com) that do not demonstrate leakage of a token, credential or session

Engaging in the following activities will result in immediate disqualification from the program and forfeit eligibility for any rewards:

• Social engineering of any kind against other customers or Peerdom staff including spearphishing attempts or contacting our support team.
• Automated scanning, mail bombing, spam, brute-forcing or automated attacks with programs like Burp Intruder.
• Denial of service: disrupting other customers’ access to their own accounts.

Payment Conditions (Optional Reward)

While Peerdom does not operate a formal bug bounty program, we may, at our sole discretion, choose to offer a monetary reward for specific vulnerability disclosures deemed exceptionally valuable. If such a reward is offered, the following conditions apply:

• Currency and Payment Method: Payments are made in US Dollars (USD), Swiss Francs (CHF) or Euros (EUR) via PayPal. PayPal is the only accepted payment method, and these are the only accepted currencies, to ensure compliance with financial regulations.

• Account Ownership: Payments will only be made to bank accounts or PayPal accounts registered in the name of the individual or legal entity submitting the report. Proof of ownership may be required.

• Payment Process: Payment will be made within 30 days after the reported vulnerability has been validated and a reward confirmed in writing.

• Tax Responsibility: The reward recipient is solely responsible for reporting and paying any applicable taxes in their jurisdiction. Peerdom does not withhold or remit taxes on the recipient’s behalf.

• No Obligation Clause: Offering a monetary reward is entirely discretionary. If a reward cannot be processed due to legal, technical, or compliance issues, Peerdom reserves the right to revoke the offer without liability.

Safe Harbor

When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be:

• Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy;
• Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls;
• Exempt from restrictions in our Subscription Terms that would interfere with conducting security research, and we waive those restrictions on a limited basis; and
• Lawful, helpful to the overall security of the Internet, and conducted in good faith.
• You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further.

Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties.